markqvist / RNode_Firmware

RNode is an open, free and flexible digital radio interface with many uses
https://unsigned.io/rnode
GNU General Public License v3.0
166 stars 56 forks source link

Bug in DCD #3

Closed ve2yag closed 5 years ago

ve2yag commented 5 years ago

https://github.com/markqvist/RNode_Firmware/blob/cec3cda7c9c4a065cb5a6d728bd530faa50802a5/RNode_Firmware.ino#L502

First line was OK, but 2nd and 3th line always return FALSE, because: status & SIG_SYNCED == 0x01 status & 0x02 == 0x01 Always return false

and status & RX_ONGOING == 0x01 status & 0x04 == 0x01 always return false too.

take note, the RX_ONGOING status bit seem to be set when RX is active, always return 1.

ve2yag commented 5 years ago

I just make some test, sending packet with one modem and watching register on another modem. This is my result:

Register value (&& 0x0F to keep only flag) Modem Idle: 0x04 (I also see 0x02 when connecting antenna and receive garbage or interference) Flag receive: 0x05 Packet receiving: 0x07 Modem return to idle: 0x04.

Here a capture of screen of register read. 5 bytes packet, BW 7.8KHZ SF7 CR4 (very slow), flag readed each millisecond: 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

markqvist commented 5 years ago

Thanks a bunch for catching this and reporting it. I'll implement a correction and test it out one of the next days, and have a firmware update out. Thanks for taking the time to do a trace of the status register!

markqvist commented 5 years ago

Just out of curiosity, can I ask you what hardware you are running this on? Did you built an RNode board with a SX1276 module and atmega1284p board? I'd love to know what boards you used, to have an idea of compatibility.

ve2yag commented 5 years ago

I make some test to implement a high speed packet network around my town, using Lora at full speed if possible and using IP over AX25 build-in into Linux kernel. Purpose is to remote configure our 144.390 APRS digipeater, making a Lora digipeater for APRS (dual port APRS) and have a receiving telemetry network to catch our HAB lauch twice a year. (successfully receive Lora packet at 3500bps, 250km from lanch site, at 30km height)

I already setup IP over AX.25 on our 1200bps APRS network, using Raspberry Pi (With Direwolf) at both end. Some tweak needed disabling Samba broadcast on AX0 port and stretching ARP protocol timeout. All working good, Telnet SSH and FTP over AX.25 packet.

Now I have two Raspberry Pi 3 with Lora RA-01 module on 70cm on top, I make radio link test between both board using Lora. I love your protocol, I want to use the same protocol but using Raspberry Pi as host for now, I create a TCP port for Kiss (Like Direwolf at port 8001) and I can use socat command to create a device to "Kissattach" Lora modem to AX25 networking of my Pi.

Good work!!

73 de Remi, VE2YAG.

P.S. I also write code and design schematic of YagTracker. My Friend Jason sell them for me, but this is now a old project. http://www.rpc-electronics.com/yagtracker.php

markqvist commented 5 years ago

Great work, sounds like some amazing projects! If you get the LoRa APRS digi up and running, please let me know the callsign, so I can take a look at it on aprs.fi!

I think the issue should be fixed now, at least it works the right way according to the status registers, but for some reason it still seems a little slower to detect a carrier than I would like. I'm going to close the issue for now, but if you find any more insights into this, please let me know!

ve2yag commented 5 years ago

My code is near finish, you can see digi there: https://aprs.fi/info/a/VA2AIG-1

It's my test site, but digipeater are on my desk right now, 5 km south of there. You can see telemetry channel 1, see li-ion cell discharging, I hook a solar panel on it when I install my digi outside.

ve2yag commented 5 years ago

Digipeater is a Atmega168 with RA-01 module and li-ion 18500 cell. The "gateway" I am using to send data to APRS-IS is a Raspberry pi with RA-01 or SPI port, running my own driver to create Kiss-over-IP radio port, I run Yacc on PC, connecting to this radio port and sending data to internet. The first byte of Lora packet ident the protocol I use, 0xA3 mean APRS or AX-25. I receive many false packet with good CRC during the day, also I can run other protocol in parallel using other ID. (radio setup, freq. adjust or new data rate, etc...)

Also I check frequency error between my RA-01 module using my SDRplay receiver, I adjust one module +1Khz, the other -3khz. Crystal was not too precise in these cheap module. I make more test in cold, if frequency drift too much for 20.8KHz bandwidth.

ve2yag commented 5 years ago

You said the carrrier detect seem slower to detect but I see in code you add flag value and wait a certain sum level to trig a carrier detect.Hardware take care of carrier detect, you don’t have to filter them like analog afsk when detecting phase sync, just check the flag to trig a carrier detect. Work like a charm there.

Envoyé de mon iPad

Le 21 janv. 2019 à 07:13, Mark Qvist notifications@github.com a écrit :

Great work, sounds like some amazing projects! If you get the LoRa APRS digi up and running, please let me know the callsign, so I can take a look at it on aprs.fi!

I think the issue should be fixed now, at least it works the right way according to the status registers, but for some reason it still seems a little slower to detect a carrier than I would like. I'm going to close the issue for now, but if you find any more insights into this, please let me know!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.