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 ?
