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 > -- Pardon the brevity, sent from a mobile device. So there. _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
