Faraday Range Testing

[el-iso]

Summary

I am planning to do some range testing of Faraday with my friend Kevin (KA9UBD). @kb1lqd Suggested that I post an issue to discuss the best methods to setup the test and how to collect useful information for the overall Faraday project.

Problem Explanation

We are planning to setup one faraday node at a high point in our area with a base station antenna. The other node will be in our car plugged into an internet connected computer running proxy, telemetry, and APRS. Upon setting up the base station node we will drive until we lose communications with the base station recording telemetry the whole way.

Questions

• Brent ( @kb1lqd ) suggested that testing transmissions at varying power levels would be beneficial. What would be the best way to control that in the code? It seems like this might require putting a computer at the base stations as well?
• What other modification to code or our testing setup would be beneficial?

This will be our first real project with Faraday other than when we did setup, so any suggestions or advice on how best to run the test would be very appreciated.

[kb1lqc]

@el-iso thanks for making this test public! Here are some thoughts:

• Power levels are currently only set by firmware update so it's not the easiest to change on the fly. Changing power levels could be interesting but also take one step at a time and possibly just focus on highest power for now.
• Make sure to test everything a day or so prior, make sure you're ready to go from a Faraday and APRS perspective. Morning of issues suck.
• Keep the radio horizon in mind, it will absolutely reduce your range.
• If you can use a better antenna than the whip on the car unit then that's awesome but not required. The Faraday whip antennas are great for whip antennas but still don't compare well against a great base station antenna or yagi.

Another thought though definitely on a whim is that you could have something similar to hello world but modified for RF to command from the base station to remote unit to blink the LEDs. Then as you're driving around you can see visually when the radio stops receiving the commands from base station.

Hope this helps!

[el-iso]

Thanks! @kb1lqc

We were planning to try for a test today, but it looks like we might be getting some bad weather so were going to postpone. Kevin Price and I are going to work on some prep and testing today though, so I will keep all these in mind! Especially the "hello world" type program that would be useful.

As far as results of the any range testing we do I'll plan to write a report of what we see. Would you like me to share the contents of the database after the fact?

Thanks again!

[kb1lqd]

@el-iso I think now is the right time for me (or others) to try to pull in RSSI data from the CC430 so you can have a metric other than "it worked" or "it didn't".

What is needed to do this is to capture this data at the lowest level of the CC430 layer 2 packet and bring it into proxy. The issue here is how to align it with received data 1:1 in the same or similar queue, or if we should. All in all, RSSI is already in the unit but not sent over UART.

[el-iso]

I agree completely I think that would be awesome. Kevin and I discussed this several times during our test. We knew some kind of RSSI must exist somewhere but we didn't know if we actually had access to it. You've just answered that question for us.

…

On May 31, 2017 1:16 AM, "Brenton Salmi" ***@***.***> wrote: @el-iso <https://github.com/el-iso> I think now is the right time for me (or others) to try to pull in RSSI data from the CC430 so you can have a metric other than "it worked" or "it didn't". What is needed to do this is to capture this data at the lowest level of the CC430 layer 2 packet and bring it into proxy. The issue here is how to align it with received data 1:1 in the same or similar queue, or if we should. All in all, RSSI is already in the unit but not sent over UART. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXZdHvwTF-MY4z1hlG3KHkYuj1vzPB6uks5r_QW0gaJpZM4Nl0g_> .

[kb1lqd]

@el-iso https://github.com/FaradayRF/Faraday-Firmware/blob/master/RF_Network_Stack/rf.c#L242

[kb1lqc]

Any update on this @el-iso ?

[el-iso]

Yes! Sorry I forgot to report back! Incoming....

[el-iso]

Summary

The results we got in general were really good. The maximum range we recorded was roughly 10 miles, but we thought we could have gotten 20 (on the next big high point in the area) but we had to cut our test short.

There were a couple really important things we learned from this test. The first has to do with our setup. We had a base station on a big hill and then we had a second faraday node connected to a computer with internet access (for aprs) in the car. We did this mainly because it was simple, but it meant that the data we uploaded to aprs showed the path of the car regardless of whether we were communicating with our base station faraday node. A better setup would have been to put a raspberry pi or other computer on the hill with the base station and run APRS on that computer so that any location data uploaded to APRS.fi would have to have been received over RF radio.

The second important thing that we learned was that terrain was a really big factor for the faraday nodes to be communicating. North West Arkansas is extremely hilly. Our base station was on the highest point we had access to which is about 300' above "average" terrain, but there are a lot of hills and valleys so basically every time we got to the bottom of a hill we lost connection.

Possible Problems

• Our mobile setup was pretty complicated. We had a computer running proxy/telemetry/aprs and we ran a USB cable to the roof where we had a faraday node mag mounted to the roof. So there could have been some problems there.
• At one point we lost cell signal (our source of internet connectivity) and it seems like it may have caused some issues with APRS, but we didn't see this until after the fact so we don't know for sure.
• Initially we were using the /stations page to see when we were communicating with our base station, however after a while we realized that the /stations page doesn't update very frequently so that was an inaccurate metric. We switched to looking directly at the database using a sql query that showed us the most recent packets from a particular nodeID.

Inconsistency

There were several times in which we thought we should have been communicating with our base station really well, but for some reason weren't receiving any packets. One specific time this happened was at a very high point that had line of sight to our base station site. We originally thought we were having hardware problems, but that doesn't seem to have been the case.

Questions/ Thoughts for Future Tests

• To what degree can the frequency of packets be controlled? I know there is something for this in the configuration but we were never quite sure how often we should be getting packets.
• I think a modification to simpleUI could be really useful for range testing. I will probably try to work on that before my next test.
• Did I leave any topics out anyone would like to hear about? @kb1lqc @kb1lqd

Conclusion

The thing I came out of this test thinking immediately was that we needed to do it again. We figured out a lot of things we did wrong, so doing another test would probably give very promising results.

In general though, 10mi in sub optimal radio terrain is a great result!

[kb1lqc]

This sounds great @el-iso thanks for the write-up! You can certainly program the radio to transmit up to 1 time per second while configuring the radio (i.e. when you program callsign). It's simply the TELEMETRY_DEFAULT_RF_INTERVAL=1 and is in seconds.

We can definitely update SimpleUI with this experience, lets chat more about it and get some ideas flowing.

I can see how it would be frustrating to not trust if RF was being received. This might be something we could allow configuration to tie to a LED such that if RF was received in the last 1 second or something the LED turns on for a second or half a second (the actual RF is pretty short so it would be hard to see).

Lastly, /stations is simply an agregate of stations heard in the last 5 minutes. This can be changed in the code (I should make it a configuration options in the .ini file....). This way even if you unplugged the remote unit it would still show up on /stations until 5 minutes after the last transmission was received. This is not ideal but simplified things like developing for the APRS program. I think this will be optimized as we move along to something more reasonable. Sorry for the confusion, this is great feedback to understand what your assumptions were.

[kb1lqc]

HEy @el-iso any chance you want to do any testing to close this Issue ticket out? Might have been that faraday-aprs unreliable connection issue I just fixed.

[kb1lqd]

Poke @el-iso ! We just merged PR #273 which should fix your telemetry/APRS cutout issues.