-
Sun 2019.10.06
Good Morning Terrence,
Nothing immediately stands out, and having a solid power bank should rule out a power issue.I posted a link in #3
GATT connection timeout?
It would be really helpful to others is you would post the output as was done as the first #1 posting shows there, when connected and any state when not connected if possible.
Confirming we have: 'MDBT42Q with software version 2v04'
and is that with the breakout board or just the 42Q module itself?
Hi Robin,
I experimented with this some more now. I simplified the setup and removed the TX/RX Serial1 lines, so only using Web Bluetooth to connect the MDBT42Q to the IDE.
I am connecting to this sensor:
https://www.aspion.de/en/transport-data-logger-aspion-g-log-2/
I have the protocol specs but cannot provide them as they are not public. The sensor behaves like a Nordic UART. I am pretty sure the sensor is the not culprit as I am seeing the same MDBT42Q behavior using the nRF app as a peripheral.
Thanks for the hint with the power supply. I just switched to a fresh 4 x AA (6V) battery power supply, so power should not be an issue ... and it doesn't appear to be (no change in behavior).
Right now, the MDBT42Q is just very unreliable. I can connect to the sensor and get data with the Android nRF app reliably 100% of the time, but executing the below MDBT42Q code gives me the following results:
I see the same behavior regardless of whether I freshly power-cycle the MDBT42Q or run the program several times in a row using the IDE upload button. I also checked the Bluetooth traffic in my vicinity but the nRF app actually only sees about 10 devices advertising, so traffic density is not a problem (my 2.4 Ghz WiFi environment is also not crowded) ... and again, the Android nRF app works fine so the wireless environment is likely not the issue.
At this point the evidence points to a bug in the Espruino stack making the MDBT42Q too unreliable to be useful.
Thanks,
-- Terrence