Gretings!
I'm building data streaming from Vems ECU to RaceChrono and I'd like to ask for advice.
The ecu has no can/obd but has AIM stream, so the first idea was to catch the stream, parse, send it as fake CAN stream via BLE.
The most satisfying is I've bought seeed XIAO nRF52840 board and done this in one night, that's was not so tricky:
00001ff8-0000-1000-8000-00805f9b34fb sevice
two characteristics:
00000001-0000-1000-8000-00805f9b34fb BLERead | BLENotify
00000002-0000-1000-8000-00805f9b34fb BLEWrite
Connected this as BLE DIY
And this started working, you may see few seconds of my screen capture
https://www.youtube.com/shorts/FX1ggpuo_lYMy special thanks for everyone who shared their experiments, I'll do the same after some cleanup.
Maybe it was a good moment to say myself "well done" and stop but I decided to try to do some extra steps.
Doing like I've done I may share any data grouped into any possible fake can packets which need to be decoded on the racechrono side (which is also not a big deal)
So I decided to try to simulate some OBD BLE adapter and send data per request. In this way I understand that requesting individual pids are more time costly, at the same time configuration on the racechrono side may be much easier, just add pids.
So, I taken a look at some $5 chinese BLE ELM327 which exposes
0000fff0-0000-1000-8000-00805f9b34fb Service with the following characteristics
0000fff1-0000-1000-8000-00805f9b34fb, BLERead | BLENotify
0000fff2-0000-1000-8000-00805f9b34fb BLEWrite
I done the same and expected I'll use read/write characteristics as TX/RX of ELM serial protocol
First run was quite promising, I saw in terminal that my board receives ATZ command
I see also 0x13 every few seconds sent by racechrono and ... nothing more.
I tried to send back different responses, different line endings, nothing helped.
May be you can give me an idea what am I missing with the OBD BLE simulation?
Comments
Maybe this helps:
https://github.com/HerrRiebmann/KDS2Bluetooth/tree/master/Bike_Diagnostic_System
There is a list below the code.
Within the code, the AtCommands.ino processed the requests. And sends due to the response type
[OK] + CarriageReturn (0x0D) + Prompt (0x3E)
where OK is mostly needed if no other result will be responded.
And one more question, can you suggest any tool which is comfortable to monitor multiple characteristics?
May be 0x3e does the trick, I'll try
Yes, that's it
for DIY uuid binary data to be sent (4bytes id + variable length data), that's already working good, your and timurrrr examples are great to be followed
for OBD uuid (carista-like) ascii terminal protocol to be used, I'll try to do it like @TriB described
your message was very helpful, 0x3E was the key of my problem, communication RaceChrono <--> fake obd estabilished
Going forward!
Many thanks for your advices, them made this working
Next step is to test it in the car.