I am facing an issue while trying to connect my WiCan to realdash, on my 2021 jeep wrangler (manual transmission) i have also tried connecting it to other cars as well and the issue still persists. I followed the exact steps of the video posted on meatpi.com website,
The device i am using is Nothing Phone 2 Android 14 OS.
Settings are:
Mode: AP
AP Channel: 6
CAN Bitrate: 500k
CAN Mode: Normal
Port Type: TCP
TCP/UDP Port: 3333
Protocol: realdash66
MQTT: Disabled
Settings in RealDash (connecting on android device via Bluetooth)
Adapters (CAN/Lin) → RealDash CAN → Bluetooth → WiC_XXXXXX → CAN Monitor
My WiCan is updated to the latest version firmware 2.98 and my hardware version is v3.00_obd
I had many connectivity issues with this device and specifically I wanted to use Bluetooth so the device (Android) was able to hotspot the internet using the WiFi interface. Try firmware revision 2.10 beta, they compiled this in response to my query and it has been rock solid for Bluetooth connectivity, subsequent revisions (I only tried up to 2.70) did not work reliably.
I have same issue, I searched the forum and docs but didn’t not found too mush about this. I made a own firmware based on the info what I found here, both iOS and adroid version timed out. then I downloaded the MeatPi V210beta, compiled/loaded to the board but nothing changed. On the other side both MeatPi and my own firmware sucesfully can connect and comunicating with almost ANY BLE terminel on both OS. So my question is what the rules to keep the connection alive ?, with “RealDash CAN” what characteristics (IDs) need to be implemeted ?, How the configuration frame works ?, What data we need to send to realdash (whithin ? period) to keep the conenction alive ?
@HondaRulez there is no inactivity timeout with RealDash I am aware of. You should check the MeatPi configuration for battery level shutdown. I had been using mine in a Toyota and moved to a Mazda recently and had to adjust this from 12.0 from 12.2 to stay on
I guess, at the connection stage at least one reply or packet required to consider the connection is alive…, BTW as I mentioned both firmware works fine with any other BLE terminal…, no matter how the hardware connected to the system or just on a bench..
Ok, connection problem solved, RD requires to get at least 1 frame within about 2 second.
Another issue was at the connection management, RD subscribes to the CCCD just after the connection made to the BLE device. This charactersitic mostly not handled on the devices but seems to be important, so we need to watch the host what set on this characteristic and we must to do the things according to. (MeatPi firmware drops these bits..)
The question what left, any docs about the “67” frames ?
@HondaRulez hi, I just migrated to a new Android device and all my timeout problems are back even with the V210beta fw. Just wondering how you overcame the timeout problem?
I faced this issue while I developed my own firmware, The important thing RD will not querying anything just waits on valid frames. In case of BT connection the firmware must send the frames just after the port opened, in case of BLE we need to send the frames just after the host sets the bit0 in th 0x2902 (CCCD) characteristic, about the MeatPi FW, if no any comminication on the CAN bus the firmware will not send anything to the host, so that will timed out continously…
@HondaRulez by way of an update I seem to have this working reliably with the latest 4.12 firmware, using NRF Connect to establish a BONDED BLE connection to the MeatPi device. I am assuming this is speeding up the BLE connection time and therefore, eliminating the RealDash timeout delays. Pity this is not documented somewhere.
No, it’s a different device.. (BTW I alway do my own work from scratch to eliminate others errors, what may not visible at the 1st pass..) and do protocol conversion between the different ECU firmwares and PC/Mobile apps…, I checked MeatPi FW just for how to make visible the device on iOS…, Finaly I choose a little different way becase MeatPi FW hurts the “BlueSIG’s manufacturer code” part if the product going to be production release..
