Meshtastic

Board recommendations

Hey all!

Greetings from Brisbane Australia. Forgive me if this post doesn’t fit with guidelines. I’m new to all this.

I bought a pair of TTGO ESP32 LoRa V1s some time ago and realised recently they were compatible with this project. I’ve been having some issues with them though.

One of the boards won’t flash unless I hold the ‘rst’ button while esptool connects. I figured that one out, but it’s made for some really weird behaviour when using the python API to change preferences. Apparently this is a manufacturing oversight?

The same board also keeps asking to be re-paired over bluetooth. I recall seeing a post somewhere mentioning that some of these boards have an issue with corruption and this can cause the re-pairing issue.

The other problem I’ve been having with both of them is that as soon as they sleep, messages won’t be received for a long time if at all. I’m not sure what the expected behaviour is for when a node is in sleep mode? Is it supposed to take upwards of 15mins?

I’d love to get my hands on some T-Beams as they seem to be the recommended way to go. Have these problems occured for anyone with the T-Beams? I noticed there are also a few of you guys looking at using nrf52 and a new prototype board from TTGO coming out with an e-ink display. I’d love to get my feet a little wetter and just wondering what the next recommended step for a beginner might be.

This is a great project! I’d love to know more and get a bit of a meshtastic community going on down here in Brisbane, but I’m very new to all this, so apologies for the questions :sweat_smile:

Caleb

1 Like

Hmm. What version # of the firmware are running on the boards? What version of the python api?

I’m running version 1.0.0 on both boards and python-meshtastic version 1.0.13 :slight_smile:

Hmmm. Sorry one more question - what model of phone?

I know you have a different board, but today I was having issues with 3 of the TBeams, it seemed they would go to sleep and nothing I did would wake them up. At first I thought maybe it was bad batteries (I salvaged them from some drill batteries that had a dead cell) Then I thought it could have been the bluetooth on some older devices, but i was consistantly having the problem from Android 7,8 &9. Which also didnt make sense, because we should be able to leave the radios powered without having a mobile paired. I did notice 1 of the radios had not been updated to the 1.1 firmware and was still running 0.7. I updated that to match the other 2, then I thought maybe the fact that they were all still on the default channel of Very Long Range and being all in the same room was causing some problems. I went down to Short Range on all 3 and I havent had a problem since. I have left them laying around the house, 1 powered via USB with no battery, 1 with battery and powered and the last one just on battery. I also took 1 for a drive and it reconnected to the other 2 as soon as I got back in the driveway. Where as earlier this morning, it appeared as though they were locking up and not waking up for anything. One last thing, once I changed the channel name & option, neither radios appeared to communicate until I performed a power cycle.

No worries @geeksville! Greatly appreciate the help. It’s a Samsung Galaxy A31 running Android 10.

Thanks for the suggestions @satkiwii! I know for sure I’ve left them on the default “very long range” all in the same house for testing so I’ll definitely try changing that.

I seen that happen too on my Tbeam v1.0 after manual channel settings change.

really puzzling - especially the part about forgetting pairing. Which is most concerning to me - and wouldn’t be fixed by a TBEAM. A few weeks ago we had a bug about that but it seemed definitively fixed. For the code on the device, you are using our release bins? (i.e. you aren’t building it yourself?)

@geeksville Yeah, I’m using the release version. It only seems to be happening on the one board though and it has given me other problems, so I’d sooner blame faulty hardware than your code. I’m happy to keep fiddling to make sure though. Is there any way to verify a flash isn’t becoming corrupted? I’ll try reflashing version 1.0.0 when I’m home. If pairing issues persist I might buy some new boards and use this one as a repeater.

1 Like

Hmm. If flag gets corrupted it would discard pairing data but I’d also expect high chances of the executable getting corrupted the same way (and then not booting). But getting a tbeam is not a bad idea because that’s the main hardware I use (I don’t even own any lora32 boards - someone contributed that support)

Thanks @geeksville. I’ll try get my hands on some T-Beams soon. I’ve reflashed both boards with 1.1.0 because I noticed AU/NZ frequencies were added. I didn’t have to hold rst down while flashing this time for some reason. Unfortunately I’m still getting that bluetooth bonding/pairing issue. It seems to be fine for 15 minutes or so and then between every 15 seconds to 5 minutes requests to be re-paired.

Rats… I thought it was only the one board that was having bluetooth dramas, but the other keeps requesting to be re-paired now too.

Hmm. Can you try going to Android settings / Bluetooth / device / forget device and then repair and see if it then no longer forgets?

1 Like

I gave that a shot and cleared the app data too and that seemed to fix the problem! I set one of the boards up with the python command line tool to reply and took the other out for a walk and it seemed to work fine. I’ll switch the boards and try it again tonight.

1 Like

I’ve been using both boards on and off now and it seems like the constant re-pairing issue happens whenever I disconnect power from a board; going through bluetooth settings and forgetting the device pair on my phone solves that every time. Any idea why this happens? Is it something on the phone side?

Hmm. Could you open a bug on GitHub and include the serial log from your lorav1 booting? Perhaps the persistent keys are for some reason not being saved in flash.

Sorry for the late reply! It’s been a bit hectic. I’ve opened that bug report here: https://github.com/meshtastic/Meshtastic-device/issues/475

I’m guessing this line from the serial log is of interest?

failed to configure restored IRK

After that the following lines repeat:

Transition powerFSM transition=Bluetooth pairing, from=ON to=ON
Trigger powerFSM 7

I’m happy to test and fiddle but totally new to C++, so not sure how useful I can be.