Alex,
Apologies for the lengthy delay on your firmware update request. A power outage took out most of my dev computer’s RAM, and unfortunately, the system drive which also had my code on it (most is committed to bitbucket). But unfortunately, the last bit of code not committed was the code that was parsing the sysex/nrpn data. So after a big delay and expense to recover my code, I’m back up and running. Update…
I checked and verified that I was running v1.94.4557, so I updated to v1.95.4561, which on the website is the latest version. I don’t think the update made much of a difference. I dug deeper into the sysex/nrpn data coming back, and found a fairly consistent anomaly – in the middle of the nrpn dump, I would get this chunk of data, which of course is throwing off my parsing algorithms:
0xd 0xa 0x20 0x65 0x74 0x73 0x20 0x4a 0x61 0x6e 0x20 0x20 0x38 0x20 0x32 0x30 0x31 0x33 0x2c 0x72 0x73 0x74 0x20 0x63 0x61 0x75 0x73 0x65 0x3a 0x31 0x2c 0x20
CR LF e t s J a n 8 2 0 1 , r s t c a u s e : 1 ,
0x62 0x6f 0x6f 0x74 0x20 0x6d 0x6f 0x64 0x65 0x3a 0x28 0x33 0x2c 0x37 0x29
b o o t m o d e : ( 3 , 7 )
0xd 0xa 0xd 0xa 0x6c 0x6f 0x61 0x64 0x20
CR LF CR LF l o a d
0x30 0x78 0x34 0x30 0x31 0x30 0x30 0x30 0x30 0x30 0x2c 0x20 0x6c 0x65 0x6e 0x20 0x31 0x33 0x39 0x36
0 x 4 0 1 0 0 0 0 0 , l e n 1 3 9 6
I’m receiving only the hex values, but here I’m showing their ascii equivalents. Does this data make any sense to you? Ever had this happen before?
Full disclosure, I’m coding this TCP driver on an Espruino WiFi microcontroller (https://www.espruino.com/WiFi), and of course I could be causing data loss/corruption on my end, but it’s just not obvious to me where the problem lies yet. Any thoughts on this are greatly appreciated. Thanks!
