1.1.32 is a version with the problem. If it’s the repeater, that could be the source.
Obvious question … I once (ok, trice) had a problem with the usb cable. have you tried different cables.
Looks like a great job making that antenna.
Have you tried changing transmit timing? Are you using long slow or a fast one?
Amazing… I’ll try harder to get it updated.
Yes, but mostly no… I have my “known-good” cable that I used for the other 4, I can reflash them over and over and this one will not go… Also worth mentioning that that unit will respond to CLI commands just fine. Just will not reset for flashing. Kevin figures the GPIO 0 is fried.
No, I did early on, but have been on the LongSlow-1 default one for a month or more.
I’ve been meaning to ask, do nodes forward messages for all channels, or only their channel…
If I put this solar repeater up on a nearby mountain ridge/ overlooking a large area, I would want it to serve everyone, not just our private channel.
Not currently, but it is in the works. Will likely be in or after 1.2 and there will be some limitations. What meshtastic refers to as a channel is a combination of RF channel, encoding and transmission settings and an encryption key. Kevin can better explain what has to be in common for multi channel to work.
Try this … To force the ESP32 into bootloader mode – manually hold down GPIO0 low on reset (using switches or jumpers). When the flasher shows the dots that it’s trying to connect to the esp32, release GPIO0 from being held down.
If that doesn’t work, then yes. GPIO0 is fried. If it does work, then there’s a lose connection somewhere on that signal between the ESP32, the UMH3N, the SilLabs USB Bridge or the USB connector.
Wow. I have nothing to offer to this particular discussion thread other than my admiration for quite literally strapping a T-Beam and homebrew antenna to your noggin in search of greater RF range. Hats off to you, sir!
3 Likes
Thanks
I did this for about 2 days back in January… Still didn’t work now.
I did manage to get it updated OTA but thought I would share some oddities in case it helps. It was actually running 1.1.42 not 37 as I thought. I tried to update several times just from the 100% charged battery, it would fail. Interestingly, the username would change from “Everlanders-Repeater” to “Unknown b18c” as if something had updated, yet it remained on 1.1.42.
Then I connected it to USB power and went about halfway on the progress bar, and then it started over and succeeded on the second sweep of the progress bar.
Oddly, the debug page only showed ConfigComplete messages… Not sure what to make of this.
The solder joints looked fine (I’ve soldered occupationally for 2 decades…) But I reflowed them again with double flux, cleaned it all off. Measures 50Ω from the soldered connection at the board to the tip of the antenna.
I connected it to the computer and sent some messages via --sendtext and they came through albeit a bit slow.
Then I hiked 8km zigzagging 250m up the highest ridge that my unfit body would take me and placed the repeater on an outcropping of rock with a nearly a 270° view of the valley below…
Using the website shared above:
It seems like there should be pretty good coverage of the whole valley.
Still, I’m not sure if it’s working… I’m getting nodeinfo from the other units near me, but only once an hour or 2 from the repeater.
num: 3186667916
user {
id: “17c9ebdf0b18c”
long name: “Everlander-Repeater”
short_name: “Evr”
macaddr: “I\236\275\360\261\214”
position {
altitude: 1xxx
battery_level: 100
latitude_i: 17xxx
löngitude_i: -96xxx
time: 1613251042
snr: -6.5
At least the battery is charging this morning 
snr of -6.5 - How does this correlate to the signal strength?
Hopefull for the Sombrero Walk tonight.
1 Like
I’m really starting to wonder if there is some kind of issue with the code that is transmitting the packets. Is that running on the relay? If so could you have something that transmits from home base and see if the relay provides acks?
I was thinking this too… I powered down all the T-Beams except the Sombrero with the diepole and obviously the mountain repeater…
Sending messages and waiting for the check mark in the cloud icon is the best way I know to do this… At times it is very good and I get ACKs to many in a row… Other times it’s less reliable.
All these tests were all done with both units in stationary positions, line of sight to the mountaintop, 2km away.
I wonder if for for the less technically endowed, or for real-world, out and about with your phone type testing, if we could implement a ping request from within the app? for example if you send a text message with “–sendping”, any receivers that get the message could reply with a text message. I think this would be a lot easier than trying to scan debug data as it flies by, while you’re trying to walk…
I would love to be able to long press a message in the android app and see what nodes have sent an ack response and include the snr. And maybe instead of a simple check mark in the cloud icon the number of acks.
Future discussion of this should be done here: Feature Request: Long press message for stats
This is even smarter!