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..
Hi @mmain,
Do your connection issues persist after upgrading to FW 4.12?
I have periodic connection dropout issues after 15~20mins of stable connectivity - the WiFi on the MeatPi disconnects and needs to be re-established so RealDash can continue displaying data again.
Initial connectivity is rock solid though.
Running MeatPi WiCAN firmware 4.12 since May 2025 - still experiencing periodic dropouts - I have just switched to MeatPi firmware 4.13u to test that.
I do also have an issue with āButton pressā CAN send actions from Realdash to an ECU on the other end of the CANBus - the initial ābutton pressā action in RealDash activates a Digital Input on the ECU end, however RealDash seems to intermittently reset that state sporadically every 150ms from 0 > 1.
Based on the marked graph, are you sure the wifi really disconnects or itās somthing data corruption ?, by the time line, Iām unsure if the wifi will reconnects within that short periodsā¦
Hi @HondaRulez ,
No the WiFi doesnāt disconnect during a āButton Pressā action from RealDash ā ECU, as the received CAN Data from the ECU still displays and updates in real time in RealDash itself. Its just the CAN Send action that is problematic.
150ms is too short a period for Wifi to disconnect and reconnect - this Android device takes roughly 10 seconds to reconnect to Wifi if the connection is dropped.
My suspicion is that RealDash isnāt sending the CAN state frequently enough and the ECU is determining that the state is being triggered on/off, rather than remaining constant 0 or 1.
I did have to decrease the XML āwriteintervalā to 100 to prevent the ECU from toggling a āFaultā state on the CAN input, as it expects the value being sent from RealDash to be written at least every 2 seconds - while this has fixed the ECU CAN input going into āFaultā when activated from RealDash, it hasnāt resolved the sporadic on/off behavior as shown in the image above.
Reducing the writeinterval to 50ms didnāt help the problem either.
Hard to say, but for me is seems like you are experiencing corrupted CAN frames. We have zero experience with WiFi CAN adapters, we always use USB ones. Could you do your experiment with a USB adapter if that makes any difference?
