RxDuino: Technical Discussion
07-03-2012 | 03:02 PM
#51
Thanks for the info. Just posted a new nightly here, response should be good on this as i reduced the lcd refresh from 10ms to 2ms from the one Russ tested last night, named
RxDuino_7_3_2012_03_31_pm.hex
RxDuino_7_3_2012_03_31_pm.hex
07-03-2012 | 07:49 PM
#53
Thanks for reporting that. I posted up a new nightly that emulates what happens when the stock radio turns on, as well as uses a different algorithm for sending a message to the screen. Hopefully this wont disable the bluetooth and such.
The result has been that the response is VERY good in my opinion. I am also hoping that this will resolve the screen fighting issues. Please let me know
RxDuino_7_3_2012_08_40_pm.hex is the newest nightly
The result has been that the response is VERY good in my opinion. I am also hoping that this will resolve the screen fighting issues. Please let me know
RxDuino_7_3_2012_08_40_pm.hex is the newest nightly
07-03-2012 | 09:06 PM
#56
Ok here is one with literally 0'd out timings for the lcd:
RxDuino_7_3_2012_10_02_pm.hex
update: So Russ said this one wasn't that good, so i reverted back the lcd algorithm, still reduced timings on this one:
RxDuino_7_3_2012_10_30_pm.hex
RxDuino_7_3_2012_10_02_pm.hex
update: So Russ said this one wasn't that good, so i reverted back the lcd algorithm, still reduced timings on this one:
RxDuino_7_3_2012_10_30_pm.hex
Last edited by paimon.soror; 07-03-2012 at 09:42 PM.
07-03-2012 | 09:56 PM
#57
Just a heads up, I have sent a note over to someone who has done a significant amount of work reverse engineering the bus. I am hoping he will be able to help, stay tuned!
07-04-2012 | 03:56 PM
#58
Paimon,
Read through this thread. Having the same problems that Russ reported. Manual update worked. If I try to update the firmware from the console, it just quickly flashes a DOS looking window? then no change. Typing in the rst console command displays |RPM:||| and just continually repeats if left alone.
Have the batch file if you need it, but was thinking that whatever you had russ do will likely work for me. Have uninstalled and reinstalled the console, and repeated the steps a couple of times too.
Thanks,
Chris
Read through this thread. Having the same problems that Russ reported. Manual update worked. If I try to update the firmware from the console, it just quickly flashes a DOS looking window? then no change. Typing in the rst console command displays |RPM:||| and just continually repeats if left alone.
Have the batch file if you need it, but was thinking that whatever you had russ do will likely work for me. Have uninstalled and reinstalled the console, and repeated the steps a couple of times too.
Thanks,
Chris
07-04-2012 | 04:48 PM
#59
Paimon,
Read through this thread. Having the same problems that Russ reported. Manual update worked. If I try to update the firmware from the console, it just quickly flashes a DOS looking window? then no change. Typing in the rst console command displays |RPM:||| and just continually repeats if left alone.
Have the batch file if you need it, but was thinking that whatever you had russ do will likely work for me. Have uninstalled and reinstalled the console, and repeated the steps a couple of times too.
Thanks,
Chris
Read through this thread. Having the same problems that Russ reported. Manual update worked. If I try to update the firmware from the console, it just quickly flashes a DOS looking window? then no change. Typing in the rst console command displays |RPM:||| and just continually repeats if left alone.
Have the batch file if you need it, but was thinking that whatever you had russ do will likely work for me. Have uninstalled and reinstalled the console, and repeated the steps a couple of times too.
Thanks,
Chris
07-04-2012 | 06:00 PM
#60
Folks, looks like we have made some great progress with bug reporting and issue solving. If you haven't already, please update to the latest nightly (as of now):
http://www.therxduino.com/nightly/Rx...2_05_32_pm.hex
This nightly fixes a LOT of issues that have been reported, as well as the radio display bug. A few things to note
1. You will not be able to communicate with this firmware through the console. The console is using a 9600baud data rate, while this new firmware has updated the serial/usb communications to 115200. The next console update will resolve this.
2. The current default mode is "OFF". When you turn on the RxDuino you will see the welcome message and then the RxDuino will go into OFF mode. Simply press Cancel and the RxDuino will turn on. This may change in the future, and will be incorporated into the console to allow the user to change their default mode.
Please rename this hex file to RxDuino.hex and use the Manual Updater as we did before! Thanks
http://www.therxduino.com/nightly/Rx...2_05_32_pm.hex
This nightly fixes a LOT of issues that have been reported, as well as the radio display bug. A few things to note
1. You will not be able to communicate with this firmware through the console. The console is using a 9600baud data rate, while this new firmware has updated the serial/usb communications to 115200. The next console update will resolve this.
2. The current default mode is "OFF". When you turn on the RxDuino you will see the welcome message and then the RxDuino will go into OFF mode. Simply press Cancel and the RxDuino will turn on. This may change in the future, and will be incorporated into the console to allow the user to change their default mode.
Please rename this hex file to RxDuino.hex and use the Manual Updater as we did before! Thanks
weak I know!
07-05-2012 | 06:18 AM
#64
it sure is interesting to see the Satellite radio stop working after a little bit with the RxD plugged in. I cannot imagine what could be causing this, maybe the satellite radio needs control of the screen for some reason to work (i dont see why it would). I will see exactly what happens when pressing the SAT button on the OEM radio
07-05-2012 | 07:09 AM
#65
Alright so it looks like I may have uncovered some information about why the buttons on the radio are acting as they are. Basically the CAN standard defines it's error protocol as a "try fail and kill" type method. What this means is that the radio is fighting with the rxduino to display stuff to the screen....right now we have the rxduino displaying at a fast rate that you dont see the flicker from the fighting, and instead you see the rxduino displayed. After a while the radio gives up and per CAN standards it removes its peripherals from the bus to prevent further errors.
I am going to try and see if at the very least what we can do is when the RxDuino is set to "off" it will send a message to the radio asking it to reinitialize.
edit: Excerpt from CANBUS standards:
5.3.5 Node Removal
One of the more interesting aspects of CAN error handling is the ability of a node
to remove itself from the CAN bus under certain conditions. To obtain the ability
to determine if a node should leave the bus, each node maintains two error counters.
One error counter increments when a transmit error occurs and logically has
the name transmit error counter. The second error counter is incremented when a
receive error occurs and has the name receive error counter. Because it is logical to
expect that a transmitter detecting an error increments its transmit error counter
faster than the listening nodes on the bus will increment their receive error counter,
because there is a high probability that the transmitter caused a detected error, the
transmit error counter value can be used as a threshold for action. That is, once the
transmit error counter value reaches a predefined value, the node associated with
the counter will first go into an error passive state. When in an error passive state
the node will not actively transmit an error flag when an error occurs. Next, the
node will then go into a “bus off” state, which means that the node will not participate
in any bus traffic.
I am going to try and see if at the very least what we can do is when the RxDuino is set to "off" it will send a message to the radio asking it to reinitialize.
edit: Excerpt from CANBUS standards:
5.3.5 Node Removal
One of the more interesting aspects of CAN error handling is the ability of a node
to remove itself from the CAN bus under certain conditions. To obtain the ability
to determine if a node should leave the bus, each node maintains two error counters.
One error counter increments when a transmit error occurs and logically has
the name transmit error counter. The second error counter is incremented when a
receive error occurs and has the name receive error counter. Because it is logical to
expect that a transmitter detecting an error increments its transmit error counter
faster than the listening nodes on the bus will increment their receive error counter,
because there is a high probability that the transmitter caused a detected error, the
transmit error counter value can be used as a threshold for action. That is, once the
transmit error counter value reaches a predefined value, the node associated with
the counter will first go into an error passive state. When in an error passive state
the node will not actively transmit an error flag when an error occurs. Next, the
node will then go into a “bus off” state, which means that the node will not participate
in any bus traffic.
Last edited by paimon.soror; 07-05-2012 at 07:14 AM.
07-05-2012 | 04:26 PM
#66
RxDuino Console - 1.1 (Released 2012-07-05) [ View Issues ]
===========================================
- 0000005: [RxDuino] RxDuino Console Should Report When New Firmware Is Available (Paimon Sorornejad) - resolved.
- 0000013: [RxDuino] Add FTDI Driver Download To Console (Paimon Sorornejad) - resolved.
- 0000019: [RxDuino] Set serial baud rate to 115200 to match RxDuino baud (Paimon Sorornejad) - resolved.
- 0000008: [RxDuino] Console shows one precision point in version number (Paimon Sorornejad) - resolved.
New version of the console has been released. To download, fire up the current version of the console. It will tell you that a new version is available and will direct you to the setup file. Once downloaded, you will be required to uninstall your current version of the console before installing the new one.
*please hold, updating***
===========================================
- 0000005: [RxDuino] RxDuino Console Should Report When New Firmware Is Available (Paimon Sorornejad) - resolved.
- 0000013: [RxDuino] Add FTDI Driver Download To Console (Paimon Sorornejad) - resolved.
- 0000019: [RxDuino] Set serial baud rate to 115200 to match RxDuino baud (Paimon Sorornejad) - resolved.
- 0000008: [RxDuino] Console shows one precision point in version number (Paimon Sorornejad) - resolved.
New version of the console has been released. To download, fire up the current version of the console. It will tell you that a new version is available and will direct you to the setup file. Once downloaded, you will be required to uninstall your current version of the console before installing the new one.
*please hold, updating***
Last edited by paimon.soror; 07-05-2012 at 05:00 PM.
07-05-2012 | 05:02 PM
#69
Driving a Black R3
Joined: Nov 2007
Posts: 308
Likes: 0
From: Bronx, NY
I'm also not able to send commands. This has never worked for me, but I thought it was a bug in the older version.
I press enter and it ignores me, clicking submit does nothing either.
EDIT: Now I am getting prompted for a new firmware, but it crashes right after.
Might be a problem on my end...
I press enter and it ignores me, clicking submit does nothing either.
EDIT: Now I am getting prompted for a new firmware, but it crashes right after.
Code:
Faulting application name: RxDuinoConsole.exe, version: 1.1.0.0, time stamp: 0x4ff60098 Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e211319 Exception code: 0xe0434352 Fault offset: 0x0000b9bc Faulting process id: 0x1e20
Last edited by amdhunter; 07-05-2012 at 05:06 PM.
07-05-2012 | 05:13 PM
#71
Ok, now the new version of the console is Live
Note: YOU MUST BE USING THE LATEST NIGHTLY TO BE ABLE TO COMMUNICATE WITH THE RXDUINO WITH THIS NEW CONSOLE
Please download the new console at http://www.therxduino.com/media/setup.exe . Your current console will not get an update notification
Note: YOU MUST BE USING THE LATEST NIGHTLY TO BE ABLE TO COMMUNICATE WITH THE RXDUINO WITH THIS NEW CONSOLE
Please download the new console at http://www.therxduino.com/media/setup.exe . Your current console will not get an update notification
07-05-2012 | 05:14 PM
#72
Driving a Black R3
Joined: Nov 2007
Posts: 308
Likes: 0
From: Bronx, NY
07-05-2012 | 06:08 PM
#75
Driving a Black R3
Joined: Nov 2007
Posts: 308
Likes: 0
From: Bronx, NY
Ugh. I noticed the wire separating from the serial port today. Had to take it apart to shove it back in there, luckily no solder points were broken and it still communicates with my PC.
No display at all using the latest nightly. I'm putting the July 4th version on now, and will report back.
I can't downgrade. Is this by design, or did I break my device.
Just noticed a new firmware, flashing it now. (RxDuino_7_5_2012_07_00_pm)
No display at all using the latest nightly. I'm putting the July 4th version on now, and will report back.
I can't downgrade. Is this by design, or did I break my device.
Just noticed a new firmware, flashing it now.
(RxDuino_7_5_2012_07_00_pm)
Last edited by amdhunter; 07-05-2012 at 06:15 PM.