Having a really hard time with Range

Anyway, try adding a ground plane. You can use the lid from a jar and put a hole through it for the antenna.

Better yet, to make your own antenna for 433Mhz you want it to be 17.3cm for 1/4 wave or 34.6cm for 1/2 wave.
From your picture it looks like the antenna is only maybe 2cm, not a good length. You can make a dipole antenna with 2 pieces of wire of the above lengths, one going from the center pin and the other from the ground (shield) and run them in opposite directions.

https://www.easycalculation.com/physics/electromagnetism/antenna-wavelength.php

Although if your transmissions interfere with shipping containers, which is what 433Mhz is used for in North America, you might get an unfriendly visit.

It was originally a stock device, it showed 30-40% signal strength on the T-Beam screen during the walk, now it shows 80-90% - I’ll consider reverting to stock. Thanks

No, It’s held at head height for the duration of the walk…

Correct, One of the 5 was delivered 433Mhz - But as we are traveling and have no fixed address in Mexico I can’t wait any longer for a replacement. That 433Mhz unit has been relegated to a receiver only. Seems to receive fine running 915Mhz code.

Thanks, I’ll build a 1/2 wave dipole for tomorrow’s walk and report back…

1 Like

So for 915Mhz 1/2 wave each leg should be 16.4 cm

1 Like

Would soldering directly onto the board cause any issues as there is no protection against RF leakage from the connection point?

The shielding is soldered against the board in the same way the SMA connector was, I can’t see the difference…

I’m wondering if you have a cold solder joint that has increased resistance. Maybe try and check with a multimeter. Should be around 50 Ohm

Thanks for that! I built one this morning and mounted it to my largest sombrero for tonight’s walk… This one was paired to my phone. I also carried a second one with a stock antenna with the brass tube as shown before.

I still had many missed pings (guessing 50%), but it was interesting that both units seemed to get all the received messages and they both missed all the missing messages. I suppose the one that was received could have relayed it to the other.

But what was also interesting/sad is that I left another T-beam with a stock antenna 3 meters from the one transmitting the time and it too missed many of the same messages that I missed while walking. It did catch a few that I didn’t.

The server sent these every minute… I have to trust the script actually works each time…?
Current Time = 16:06
Current Time = 16:07
Current Time = 16:08
Current Time = 16:09
Current Time = 16:10
Current Time = 16:11
Current Time = 16:12
Current Time = 16:13
Current Time = 16:14
Current Time = 16:15
Current Time = 16:16
Current Time = 16:17
Current Time = 16:18

But the receiver 3 meters away doesn’t catch them all:

Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:10', 'text': '16:10'}}, 'id': 2850509587, 'rxSnr': 7.25, 'rxTime': 1613686246, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:11', 'text': '16:11'}}, 'id': 1882057581, 'rxSnr': 7.0, 'rxTime': 1613686293, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:12', 'text': '16:12'}}, 'id': 3660720756, 'rxSnr': 8.0, 'rxTime': 1613686366, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:16', 'text': '16:16'}}, 'id': 3608628701, 'rxSnr': 4.0, 'rxTime': 1613686611, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:17', 'text': '16:17'}}, 'id': 3643319722, 'rxSnr': 5.25, 'rxTime': 1613686668, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:18', 'text': '16:18'}}, 'id': 1110682246, 'rxSnr': 8.25, 'rxTime': 1613686773, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:19', 'text': '16:19'}}, 'id': 3030548374, 'rxSnr': 9.0, 'rxTime': 1613686861, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}
Received: {'from': 3186665228, 'to': 4294967295, 'decoded': {'data': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'16:21', 'text': '16:21'}}, 'id': 1596524341, 'rxSnr': 9.0, 'rxTime': 1613686944, 'hopLimit': 1, 'fromId': '!bdf0a70c', 'toId': '^all'}

Also weird that the hopLimit is 1 on all these messages when it was just the 2 units in the area…

I’m starting to think it’s not all the fault of the antenna… But I’ve run out of ideas on what to try next.

3 Likes

What version of the firmware do you have on your board? A recent build fixed a problem with retransmission of packets.

1.1.48 on these, the Solar Repeater is stuck on 1.1.32 and will not update over USB:

While it was able to update it once via OTA, it will not update to 1.1.48, it moves the progress bar about halfway and then quits. Sometimes it tries twice - but it still fails. As I link that thread I remember that I thought it was USB power that helped it succeed last time. Might need to fire up the rescue drone and get it down from the rooftop tomorrow…

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 :slight_smile:

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

:point_up: This is even smarter!