https://meshtastic.org/
Another interesting effort. Steve N0FPF On Sun, Aug 1, 2021 at 12:34 PM Steve <[email protected]> wrote: > You have to set the Rnode with the parameters you want to sniff. So I had > to set the baud rate, bandwidth and CR to match the other tracker. > > A lot of gadgets that are doing off the grid chat are using the Lora > chips. I’ve been watching these guys. > https://www.sonnetlabs.com > > They say their code is open source.. > > > > > On Sun, Aug 1, 2021 at 12:08 PM Kristoff <[email protected]> wrote: > >> Hi Steve, >> >> >> I must really look into the Rnode. >> If you say that you put the rnode into sniffer mode so you could >> determine the spreading-factor, does this mean that the Rnode can do >> that automatically, or that you just tried all of different spreading >> factors and found that SF12 worked? >> >> >> Yes, SF12 packets are long, but that is exactly one of the features of >> digital communication: the possibility to 'tune' the transmission. The >> parameters are bandwidth, bitrate (speed), transmission-power and range. >> It's like WSPR or QRSS. The transmissions are very long, but you can >> decode signals that are 20 to 30 db below the noise-floor. >> >> >> If you look at page 20 of the sx1276 datasheet (*), there are some >> examples of the RF sensitivity with different SF values. >> It's not linear, but roughly speaking, going down 1 step in the SF >> scale, you lose about 2 to 3 db of sensitivity. >> >> So if you go down 2 steps in the SF scale, your bitrate will be 4 times >> faster, but you will loose some 40 to 50 % of range. >> >> >> >> In the context of APRS, I think aprs-over-lora has a place for (say) >> portable or bicycle-mobile applications next to regular 1200 baud AFSK >> on VHF or UHF for (car) mobile use. >> So I do not think that the lower bitrate of LoRa is that necessarily >> much of an issue. >> >> I hope that aprs-over-lora will make applications like chat more popular >> as that is a feature of APRS that has deserves much more attention then >> what it gets. >> >> >> >> Note. >> I had a chat in the matrix-room of the GNU Radio community on Hamming >> FEC on the Coding-Rates. >> The conclusion at this time is that -indeed- there is no reason to use >> Coding Rates 6 or 8. In both cases, they just add error-detection >> capability to CR5 or CR7; but as aprs-over-LoRa has CRC error-detection >> anyway, this does not add any value. >> >> So the choice is this: >> CR5: no error-correction, for radio-channels with little RF interference, >> CR7: error-correction enabled, for radio-channels with more RF >> interference. >> >> >> Keep in mind that a CR7 packet is 7/5 times the size of a CR5 packet. >> >> >> >> 73 >> >> kristoff - on1arf >> >> >> (*) >> >> https://www.semtech.com/products/wireless-rf/lora-core/sx1276#download-resources >> >> >> On 01.08.21 18:36, Steve wrote: >> > Interesting that you mentioned coding rates. >> > I was sniffing OE5BPA’s Lora transmitter because Xastir is not >> decoding >> > it. I have a feeling his packets are not quite right over the air. You >> can >> > put Rnode into a packet sniffer mode, which makes it easy to see things. >> > OE5BPA’s config file has a default CR of 12… it is very long on its >> > transmission. I changed it to CR of 5. >> > >> > Just a FYI… I’m just a person who has fun using this stuff, not a >> developer >> > with coding experience .. >> > >> > Steve N0FPF >> > >> > On Sun, Aug 1, 2021 at 5:27 AM Kristoff <[email protected]> wrote: >> > >> >> Hi Steve, >> >> >> >> >> >> Interesting code. I'll look into it. Perhaps it is a better option then >> >> me building something (non-standard) myself. >> >> >> >> >> >> Concerning modifying the Coding-Rate, I think one should look at this >> >> per application. >> >> APRS is mostly a 'broadcast' service the most logical thing to do is to >> >> use one single 'standard' modulation-scheme for everything. >> >> >> >> However for a service like 'aprs-messages', although the traffic is >> >> transmitted inside a 'broadcast' packet, it is still directed at one >> >> specific destination. >> >> In that case, the igate or digipeater can operate on that. If it keeps >> >> track of the coding-rate of the last packet it received from that >> >> station, it can use that information in its transmissions towards that >> >> station. >> >> (you can find the coding-rate of the last packet received in register >> >> 0x18 of the chip). >> >> >> >> Concerning the coding-rate, yesterday I found this video from ccc 33c3 >> >> (2016), where Matt Knight explained how he reverse-engineered most of >> >> the LoRa PHY (*) >> >> >> >> There is also this document from him. (**) >> >> >> >> >> >> It had an interesting part in it where he explains the 4 >> transformations >> >> done on the LoRa datastream, one of them is Hamming-coding Forward >> Error >> >> correction. >> >> His document has this on it: >> >> --- cut here --- cut here --- >> >> >> >> A larger codeword size improves the robustness of the FEC: Hamming(5,4) >> >> and (6,4) provide error detection as a parity bit would, whereas (7,4) >> >> and (8,4) provide single bit correction with (8,4) additionally >> >> providing dual error detection. >> >> --- cut here --- cut here --- >> >> >> >> >> >> >> >> As I see it, going from FEC 4/5 to 4/7 is interesting as it adds the >> >> possibility to do error-correction of a single bit. >> >> Going from 4/7 to 4/8 does add the ability to detect more errors, but >> it >> >> cannot correct it. >> >> >> >> Now, as APRS is a datacommunication-protocol (i.e. the content of the >> >> data is unknown, so the whole packet must be correct or it will not be >> >> processed) and the LoRa frame also has a CRC field, I do not see the >> >> additional advantage of that 8th bit (i.e. 4/8 vs. 4/7). It may provide >> >> more error-detection, but CRC does that anyway. >> >> >> >> So, as I see it, it looks that if you are in a area of bad coverage, it >> >> is useful to use the 4/7 coding-rate instead of the standard 4/5, but >> >> not 4/8 (as I previously mentioned). In fact, using 4/8 creates larger >> >> packets then when using 4/7, which -I think- might be a disadvantage as >> >> a bigger packets simply has more bits that can get corrupted. >> >> >> >> >> >> But, as I not an expert on hammings FEC, I might be wrong. >> >> >> >> If somebody knows more about this, feel free to reply. >> >> >> >> >> >> >> >> >> >> (*) https://media.ccc.de/v/33c3-7945-decoding_the_lora_phy#t=2382 >> >> (**) https://pubs.gnuradio.org/index.php/grcon/article/view/8 >> >> >> >> >> >> 73 >> >> kristoff - on1arf >> >> >> >> >> >> On 31.07.21 22:38, Steve wrote: >> >>> I’ve noticed that the KISS implementation on a lot of these devices >> is a >> >>> forked over version of the Rnode. He used the Sx 1276 chip as well >> >> because >> >>> it has really good RX sensitivity at the lower rates. He also has a >> newer >> >>> and easier form of KiSSattach. >> >>> https://github.com/markqvist/tncattach >> >>> >> >>> >> >>> >> >>> I like your thoughts about changing modulation on the fly. I’ve seen >> it >> >>> done with higher level stuff , Ubiquiti and others. Just wonder how >> much >> >>> it would slow things down. Cause I think you would do that per packet. >> >>> Maybe per connection. >> >>> >> >>> Right now I’m just interested in tying a few of the different versions >> >> and >> >>> seeing what works. No real goals in mind, just checking it out and >> >>> experimenting. >> >>> >> >>> I’ve thought about a repeater, but that would kill the great RX >> >> sensitivity >> >>> , but a digi would be good. A old style repeater separated by distance >> >> and >> >>> a link would work. >> >>> >> >>> >> >>> Might even try Winlink on it and see what what happens when I stir >> that >> >> pot! >> >>> So many ideas. >> >>> >> >>> Steve N0FPF >> >>> >> >>> On Sat, Jul 31, 2021 at 12:58 PM Kristoff <[email protected]> wrote: >> >>> >> >>>> Steve, >> >>>> >> >>>> >> >>>> I also have this model: >> >>>> >> >>>> >> >> >> https://www.amazon.nl/DollaTek-LoRa32-SD-kaart-draadloze-module/dp/B07RXSKPBX/ >> >>>> The disadvantage is that it lacks the 8 Mbit PSRAM chip (which is on >> the >> >>>> T-beam) so the ESP32 is a bit short on memory for embedded python. >> (less >> >>>> then 1 MByte of RAM available). >> >>>> >> >>>> >> >>>> Software development-wize, perhaps it makes more sense to turn the >> >>>> radio-device into just a dumb 'packet-modem', connect it to a >> >>>> single-board computer (say, a raspberry pi) and do all development >> >>>> overthere. That way you can run higher-level code, easily interface >> with >> >>>> the internet, connect other devices (e.g. a VHF/UHF packet mode), >> etc. >> >>>> >> >>>> Last week, I found this python module for processing aprs message (*) >> >>>> which I think would be a good basis to do some experimental >> development >> >>>> for aprs-code. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> I do like the sx1276 chip. It has a couple of nice features. >> >>>> >> >>>> - as it also has a FSK modem, It might also be able to transmit >> POCSAG >> >>>> (paging) messages. If this works, we should be able to build a >> >>>> APRS-to-POCSAG gateway with just one piece of hardware: send a aprs >> >>>> text-message to a certain APRS node and it transmit that message as a >> >>>> POCSAG paging message. >> >>>> >> >>>> I once wrote some code to create pocsag-message. (**) >> >>>> >> >>>> >> >>>> - The automatic header-detection in lora is nice, >> >>>> This means that if you send a packet with (say) a coding-rate of 4/8 >> to >> >>>> a lora-node configured with 4/5, the chip will still receive and >> decode >> >> it. >> >>>> So, if you know that you are in area with bad APRS-over-lora >> coverage, >> >>>> you can switch to a coding-rate that provides better error-correction >> >>>> (like 4/8). Your packets will become larger (by 37.5 % in this case) >> but >> >>>> your packet might still arrive, which it might not have done with a >> >>>> coding-rate of 4/5. >> >>>> >> >>>> Note that that bandwidth and Spread-Factor do need to match. If not, >> >>>> your packet will not be demodulated/decoded. >> >>>> >> >>>> - Another nice thing is that, although the chip does have >> CRC-generation >> >>>> and CRC validation in silicon, it will still pass packets to the >> >>>> receiver, even if they fail the CRC check. >> >>>> It will flag it as 'CRC error', but the code on application-level >> will >> >>>> still be able to retrieve it. >> >>>> Most other radio-chips I have looked at so far do have do not do this >> >>>> and will silently drop that message. >> >>>> >> >>>> This would allow for a nice lora "DX-ing" mode by implementing >> >>>> additional error-correction code on application-level. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Ah yes, there is also a GNU Radio implementation of the Lora PHY. >> (***) >> >>>> I haven't tried it yet, so I do not know if it works but It would be >> >>>> interesting to experiment with this, e.g. tweaking the parameters >> even >> >>>> further to do even further DX. >> >>>> >> >>>> >> >>>> >> >>>> I am not on Facebook. >> >>>> >> >>>> I prefer mailing-lists for in-depth discussions. To get real-time >> help, >> >>>> ... I am on matrix / element.io which is an open-source and >> >>>> decentralized IM/voice/video service. >> >>>> There are quite some open-source groups reachable via matrix, either >> >>>> directly on matrix itself or via bridges to IRC or some other IM >> >> protocol. >> >>>> It's used the GNU Radio community. >> >>>> >> >>>> >> >>>> (*) https://github.com/ampledata/aprs >> >>>> (**) https://github.com/on1arf/pocsag >> >>>> (***) https://www.epfl.ch/labs/tcl/resources-and-sw/lora-phy/ >> >>>> >> >>>> >> >>>> 73 >> >>>> kristoff - on1arf >> >>>> >> >>>> >> >>>> On 31.07.21 20:31, Steve wrote: >> >>>>> I gave two of the TTGO units including a couple of Rnodes. >> >>>>> >> >>>>> I’m going to try a couple of the existing firmware options out >> there. >> >>>> Some >> >>>>> are KISS based some are not. I like the possibility of using the >> wifi >> >> or >> >>>>> Bluetooth with the TTGO with some of the APRS programs fir the >> phones. >> >>>>> >> >>>>> Seems for a mobile device, not have a extra board such as a PI >> might be >> >>>>> nice… we’ll see! >> >>>>> >> >>>>> The TTGO can also be used for this: >> >>>>> https://tinygs.com >> >>>>> >> >>>>> The Rnode guy is also implementing a MESH system but is only in the >> >> alpha >> >>>>> stage. Beyond my ability. >> >>>>> >> >>>>> I’ll have to get back to you on Freq, I only got my TTGO going last >> >> night >> >>>>> and didn’t bother to look! >> >>>>> >> >>>>> There is a LORA APRS group on Facebook, grin, that is mostly from >> >> Europe >> >>>>> who have a lot of experience with this . >> >>>>> >> >>>>> Steve N0FPF >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Sat, Jul 31, 2021 at 11:20 AM Kristoff <[email protected]> >> wrote: >> >>>>> >> >>>>>> Steve, >> >>>>>> >> >>>>>> >> >>>>>> Your project interests me too. >> >>>>>> >> >>>>>> We are using this hardware: >> >>>>>> https://github.com/LilyGO/TTGO-T-Beam >> >>>>>> >> >>>>>> We are on 433.775 MHz, 150 KHz, SF12, 4/5 >> >>>>>> What frequency and what mode do you use? >> >>>>>> >> >>>>>> >> >>>>>> The software comes from this project: >> >>>>>> https://github.com/lora-aprs >> >>>>>> But if the code of your project is standard arduino, it shouldn't >> be >> >> to >> >>>>>> difficult to port it to ESP32. >> >>>>>> >> >>>>>> Apparently, there are also some high-altitude balloon projects that >> >> use >> >>>>>> lora for their telemetry download. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> My personal interest is to use this for doing some software >> >>>>>> experimentation, so I use micropython on the ESP32 (fast >> development) >> >>>>>> and not the arduino code. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> 73 >> >>>>>> Kristoff - on1arf >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On 31.07.21 20:05, Steve wrote: >> >>>>>>> I connected it to my 10 db Omni antenna at home right at the base >> to >> >>>>>>> minimize the loss. >> >>>>>>> >> >>>>>>> I was impressed that it was heard around some of the hills in west >> >>>>>> seattle . >> >>>>>>> I have plans to put a IGate at a high point around the end of the >> >>>> summer. >> >>>>>>> I also found a small bi- directional amp too. Boost it to a watt >> or >> >>>> two. >> >>>>>>> Just don’t want to kill the receive sensitivity. Around $60. >> >>>>>>> >> >>>>>>> It’s all in the antenna. >> >>>>>>> >> >>>>>>> Steve N0FPF >> >>>>>>> >> >>>>>>> >> >>>>>>> On Sat, Jul 31, 2021 at 10:59 AM Tom Russo <[email protected]> >> >> wrote: >> >>>>>>>> On Sat, Jul 31, 2021 at 10:35:44AM -0700, we recorded a >> >>>> bogon-computron >> >>>>>>>> collision of the <[email protected]> flavor, containing: >> >>>>>>>>> I have interfaced the Rnode Lora device. It does Kiss and used >> a PI >> >>>> 3. >> >>>>>>>>> Pretty straight forward. >> >>>>>>>>> >> >>>>>>>>> https://unsigned.io/projects/rnode/ >> >>>>>>>>> >> >>>>>>>>> I was able to do a client and a IGAte. >> >>>>>>>> That is pretty cool! >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Tom Russo KM5VY >> >>>>>>>> Tijeras, NM >> >>>>>>>> >> >>>>>>>> echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr >> >> [a-m][n-z] >> >>>>>>>> [n-z][a-m] >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Xastir-dev mailing list >> >>>>>>>> [email protected] >> >>>>>>>> http://xastir.org/mailman/listinfo/xastir-dev >> >>>>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Xastir-dev mailing list >> >>>>>> [email protected] >> >>>>>> http://xastir.org/mailman/listinfo/xastir-dev >> >>>>>> >> >>>> _______________________________________________ >> >>>> Xastir-dev mailing list >> >>>> [email protected] >> >>>> http://xastir.org/mailman/listinfo/xastir-dev >> >>>> >> >> _______________________________________________ >> >> Xastir-dev mailing list >> >> [email protected] >> >> http://xastir.org/mailman/listinfo/xastir-dev >> >> >> _______________________________________________ >> Xastir-dev mailing list >> [email protected] >> http://xastir.org/mailman/listinfo/xastir-dev >> > -- > Pardon the brevity, sent from a mobile device. So there. > -- Pardon the brevity, sent from a mobile device. So there. _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
