This is what I'm trying at the moment. Initially I didn't think it was doing anything, but when I dropped the blankInterval down below 10 I started to get random newMessage results. With blankInterval set at 4, I just get a continual stream of 'New Message' in the serial monitor.

BlankInterval between 5 and 15 seem to just give random 'New Message' or 'read next byte' and 15 and above just gives 'read next byte' for each HEX byte that is sent. I'm not quite sure what this is telling us, and I don't understand why the blankInterval needs to be so low before it starts to react. Hi, Ian, I've been thinking a bit more about this. It seems to me that (assuming the gap between messages is the correct delimiter) the gap should be all that needed to separate messages.

If so this code should work. It should save 8 messages and then start overwriting them so it always has the most recent 8. For testing, perhaps you could modify loop() so it stops calling getIBusStuff() after 8 messages have been read. Obviously this isn't tested. Because the interval is in microsecs very short numbers will be completely meaningless.

To use NavCoder you need a laptop with Windows (anything from Windows 2000 to Windows 7; it may still work on Win95, but I cannot test it on Win95 any more) and an ibus interface. The ibus interface is the necessayr hardware interface to convert the electrical signal of the BMW ibus into good old RS232 for the laptop.

As far as I know Serial.readbytes() is a a blocking function and I don't see any advantage in using it with a data stream as slow as 9600 baud. The timeout would need to be long enough to wait for the whole of a long message so I think it would get in the way if you inadvertantly start sampling in the middle of a message. One of the things I like about my suggestion (always assuming it works ) is that it deals with all bytes with the same code, doesn't require special cases and will jump to start a new message whenever the delimiting gap occurs.

Figuring out the content can come later after the message has been received.R. I reckoned I might be able to write a short PC program to simulate thee output of the IBUS system in a very basic way - just sending a few strings of different lengths with a gap between them - to test my Arduino code.

Not surprisingly there were a few silly mistakes in the code I posted earlier. Following is a complete sketch that seems to work. I have written it for a Mega because it has multiple hardware Serial ports. If you want to write to the Serial Monitor with SoftwareSerial just replace the references to Serial1 with whatever you call your instance of SoftwareSerial.

In case others are interested I had the Mega connected to the PC through the normal USB cable and I used an FTDI cable to connect Rx, Tx and GND for Serial1 to another USB connection on the PC. That allowed me to view the output through the FTDI cable on the Serial Monitor while another program (written in JRuby) sent data to the Mega over the normal USB cable.

Hi Robin, Right, I've loaded your program into the Arduino and after a couple of small changes to the Serial setup (need 8E1 for IBUS), I was ready for testing. As soon as I power up, I see the 'Serial Works' prompt. If I send one 6 byte message (50 04 68 32 11 1F) I get nothing on the serial monitor.

I'm assuming this is the program getting in sync with the gap between bytes. If I send the same 6 byte message I get: Msg 0 Ph2 Msg 1 P Msg 2 Msg 3 h Msg 4 2 Msg 5 If I send the same message again, I get this: Msg 6 Msg 7 P Msg 0 h2 Msg 1 h Msg 2 2 Msg 3 and the same again: Msg 4 Msg 5 P Msg 6 Msg 7 h Msg 0 2h2 Msg 1 It looks like the same characters, but the order is a little mixed up.

I'm also assuming these are ASCII which explains some of the gaps. Looking at the ASCII table, 0x04 is EOT and 0x11 is DS1 etc. Is it possible to output the bytes in hex? I've had a play with the interval and 900 seems to be a bit more reliable, but it's hard to see exactly what's coming in while it's ASCII. These are consecutive 6 byte messages (same as above). Note that the first message comes in straight away without ignoring the first message. Also note that the first message is only receiving 5 bytes, not the 6 that were sent.

It looks to be 6 from there on in though. Msg 0 P Msg 1 Msg 2 h Msg 3 2 Msg 4 Msg 5 Msg 6 P Msg 7 Msg 0 h Msg 1 2 Msg 2 Msg 3 Msg 4 P Msg 5 Msg 6 h Msg 7 2 Msg 0 Msg 1 Msg 2 P Msg 3 Msg 4 h Msg 5 2 Msg 6 It certainly looks like you're onto something though.