Antenna improved range

On your recommendation, I purchased the Superbat, and wound up getting much worse results than with the stock antenna. Hooking it up to my NanoVNA showed that the SWR was way up in the stratosphere across the board. And then I realized that the antenna has an RP-SMA female connector and I needed to use the included ‘RP-SMA Female to SMA Male Adapter’. Oops. I dug the little thing out of the trash where I had discarded the packaging materials, attached it inline, and was delighted to see a 1.24 SWR at 915 MHz.

Out of curiosity, I tested the two stock antennas that had come with the T-beams I purchased from AliExpress. One measured with an SWR of around 1.5, and the other was a horrific 14 or so! I’m amazed that it had given me the distances it did, and I can’t wait to test distance with the Superbat and ‘good’ stock antenna now.

In short, I think the NanoVNA is a very worthwhile purchase for anyone playing around with antennas, even for an RF noob like myself.

1 Like

I recently purchased a NanoVNA and started doing VSWR comparisons of antennas as well. One thing to check before you start taking down numbers is the actual frequency you’re dealing with instead of just using 915mHz as the reference point.
I happened to find out I was on the extreme end of the spectrum while looking at my channel settings in the serial logging of the meshtastic python cli. I was trying to track it down because I could see any chirps on my SDR (the next phase of my antenna tests). Turned out was looking in the wrong part of the band.
image

1 Like

Do you think that information be useful if it were easier to get to rather than from the debug log? If so, please open a feature request and I’ll put it somewhere easier to get to.

LMK the issue ID and I’ll take it on.

It hadn’t occurred to me until now, but now that you mention it, maybe showing some of the details of the channel in meshtastic --info would be very handy. I’ll put in an issue in github. Thanks!

@mc-hamster, should I put that issue in the python api github issue instead?

I’m not a strong python developer, so if you put it there, someone else will have to grab it.

Part of the issue is those values are not in the protobufs, so I’ll need grab them directly. Maybe display them on the web interface somewhere. It’ll be easy for me to put it there.

I added a complementary ticket to to the meshtastic-device to expose the details for consumption

1 Like

Very cool. I assigned the ticket to myself.

I’ll write it in a way where I’ll make an update to the radio library class so if someone wants to put it in the api later, it’ll be really easy to do.

2 Likes

The change is done.

I’m holding it back in my personal fork until I’m done-enough with another change (I have not had much heads-down time recently). It’ll be in either the next or the following alpha.

When it’s published to see your actual frequency used, turn on WiFi on your device and then go to:

http://<your_ip_here>/json/report

or

http://meshtastic.local/json/report

This is what you’ll see:

1 Like

I love it! Thanks for putting the time in to add it.

1 Like

The range test plug-in is now in private alpha testing, but I think it’s done enough. Here’s a preview:

image

The two radios are on my patio (no stockers please) and 180 degrees of the sky is blocked and the sky is very thick with clouds. It’s been raining here. That would explain the variable distance, but it’s a good test.

4 Likes

This is fantastic. It’s a much better system than me remote SSHing into my home network to check messages.

Here’s the documentation:

It’s not yet public but it does work :slight_smile:

I can imagine a few use cases that this wasn’t originally designed for that would be totally awesome and would work out of the box.

4 Likes

It’s perfect for my use case of messaging wifi connected base station node and driving to my buddy’s house with a mobile node on the roof my car to see where I get a signal. Also swapping antennas and doing the same thing for A/B tests. It’s one thing to test SWR and look at reported dbm on my SDR, but real world testing will be ideal.

That’s my use case too.

The only really difficult part with this is ensuring both ends has a good GPS lock. I’m trying out different work arounds to improve the GPS acquisition, but that may just need to be a factor of updating the other configuration settings.

Might it be worth an option to use phone GPS for this? As that will often come with the various corrections as well as typically managing a better lock.

1 Like

Good point. I actually don’t often use an android phone, so I didn’t think of those two.

For the sender, a phone would work to get location information. I’ll update the docs.

For the receiver, I don’t know if it’ll work as it is written. I get the location straight from the gps API. Either way, I’ll update the docs and add it to the TODO if it’ll need to be a future feature.

1 Like

My base node has a fixed lat, long, altitude set. So I can drive out with a bluetooth connected mobile node with one of those Eightwoods magnetic antennas you recommended mounted on the top of the car. Position figures should be pretty accurate from my phone.
I’ll probably wait to test next week, since we’re getting unprecedented low temps and snowfall this week where I live.

1 Like

I want to add this to the GUI

My fixed location base unit is a T-Lora with lat long and altitude set, when I used it as the receiver and saver for the range plugin it showed zeros for the base unit lat long, the sender data was correct.