Great, I can always revert back to old one?
Yes thats correct. 
OK, finally had a chance to sit down and do a deep dive on this today. I only have a USB connection available for this testing so this result may not apply to bluetooth, but what I’ve found is that when RD is connecting, Speeduino is receiving at least 1 additional byte in addition to just the ‘A’. This is always a non-alphanumeric value, usually above 127
I can’t say for certain whether it is RD sending this as some sort of terminator or whether it’s somehow getting inserted by Android, but these extra bytes are the cause of the issue.
In legacy serial mode (Which is what RD is using here with the ‘A’ command), Speeduino only accepts commands from [A-z] or values 0x41 through 0x7A and this is what appears to be causing the issue. If I allow all values rather than just that subset, then RD connects and works fine.
Is it possible to look at the serial debug log that RD produces directly to see exactly what is getting sent?
Ultimately it would be great to move over to the newer protocol (Which is what I’m guessing is used for RusEFI and MS already in RD), but in the mean time it would be good to understand what is going on with these extra bytes.
Can confirm now that this workaround will not fix this unfortunately. The problem turned out to be more complex than I had originally thought.
The only write to serial in entire RealDash Speeduino connection implementation is:
serialComms.Write("A", 1);
And per my tests, only one byte of ‘A’ is written to serial. Don’t really know how this would show as multiple bytes on receiving end? Well everything is possible of course.
As for newer protocol, you could try rusEFI connection and upload a proper ini file in connection settings in order to prevent RD from attempting to download rusEFI specific ini file.
Thanks for that, I assumed it would be something fairly simple but thought it was worth asking. No idea where that 2nd byte is coming from then but it’s consistent with every request. I’ll keep investigating and see if I can dig anything up.
I’ll also have a play with the other ECU options and see if I can get any of them to work
Just out of interest, I made ‘Speeduino simulator’ on Arduino nano. This script was maybe the simplest I could come up with.
void setup() {
Serial.begin(115200);
}
void loop() {
const int a = Serial.available();
if (a > 0) {
byte buf[114];
memset(buf, 0, 114);
int i = 0;
for (i=0; i<a; ++i) {
buf[i] = Serial.read();
}
buf[i] = a;
Serial.write(buf, 114);
}
}
When 114 bytes dummy buffer is written back to RealDash (default serial0 connection expects 114 bytes back from the Speeduino), first and second bytes are always 65 and 1 (‘A’ and 1 byte was available from serial).
This test was run with RealDash running on Android with USB connection. Based on this test, only one byte is written to serial by RealDash.
I did a little more digging and found that the extra byte is only occurring on the initial connection creation. The 2nd, 3rd, 4th etc bytes are all ‘A’ as expected.
What I was seeing previously was the connection continually resetting and hence sending that first random byte over and over. Almost certainly this is something that seems to be occurring as part of the serial connection, be it android or something in the hardware rather than in RD itself, but I can’t see any immediate cause of it. Trying different combinations of DTR and RTS didn’t appear to make any difference, nor did increasing the delay before connection.
I think I can probably work around this in the firmware though, I’ll just need to make sure it doesn’t interfere with any other SW.
FWIW, the rusEFI connection using a Speeduino ini didn’t work. If I get a RD subscription, is it possible to view the comms debug log?
Is that extra byte possibly a red herring? It does work with ochblocksize 122 or 125 even with the extra bite.
It does work with ochblocksize 122 or 125 even with the extra bite.
I’m not seeing this. Changing that ochblocksize makes no difference for myself. With the workaround to ignore that first byte though, everything works fine even with a ochblocksize of 127
thats just weird. Is that with the released 202305?
The debug log is not trivially accessed due that it may contain some proprietary information on some ECU connections. It can be found quite easily though if you have full access to Android file system.