RadioLib
RadioLib copied to clipboard
jgromes
Adding support for AX5043
It's a nice chip with FSK, PSK, ASK and hardware AFSK. @librespacefoundation are using it in their PQ9ish and Qubik satellites. Could be a cool addition to Radiolib. They have made a C library for it on gitlab repo https://gitlab.com/librespacefoundation/ax5043-driver @surligas is maker of the library and might as well help you with getting hands upon the module itself.
I'm aware of AX5043, I actually have a couple of them and was intending to add support, just never gotten around to it due to time constraints. So this will probably be added sometimes later.
https://github.com/NotBlackMagic/VUHFRadio found this, may help with the register. @NotBlackMagic can you help port your work on the registers to radiolib format?
I am happy to help with any questions that arise with the addition of the AX5043 radio support to this library. Maybe I can take a crack myself at it, when I find the correct inspiration and motivation :D
I have started work on this and will make a PR when I get it stable. I'm using a lot of help from your website @NotBlackMagic and a modified mbed example I got working with an arduino. I will be focusing on the AX5043 but it should work on the AX5243
The main change to the library itself will be support for 12-bit addresses.
I already have the basic "is there an AX5043 connected" and 12-bit address working.
@iangoegebuer that's amazing, thank you so much! I actually saw your fork and the >8 bit address support looks fine (as in - shouldn't break anything).
Looking forward to the PR, feel free to open a WIP one to discuss changes.
@iangoegebuer Can you update the Example Pins to show what the symbols are on the AX5043? I can't seem to match NSS/DIO0 etc to what they should be on the 5043.
@coolacid I'm not sure what you're asking. On the AX5043 they are labeled MOSI/MISO/CLK/*SEL. Take a look at the below PDF
https://www.onsemi.com/pub/collateral/add5043-169-2-gevk%20schematic.pdf
@iangoegebuer In your example INO files, you have:
// AX5043 has the following connections:
// NSS pin: 7
// DIO0 pin: 2
// RESET pin: 9
// DIO1 pin: 3
AX5043 radio = new Module(7, 2, 9, 3);
This according to the wiki should map to Module(cs, irq, rst, gpio)
However, the AX5043 does not have pins labled NSS, DIO0, Reset or DIO1 - So, I'm trying to understand what those pins should be attached to.
@coolacid NSS is marked as *SEL (not SEL or SEL with the bar over it)
The other 3 are currently unused. One will be connected to the line marked "IRQ" eventually an the other will likely connect to the line marked "DATA" eventually.
The AX5043 is reset by sending power mode transitions. See the start of "beginAFSK" in the AX5043.cpp file.
Finally made some progress recently. I was unable to receive any AFSK data with a known working module. It turns out some of the AX5043 dev modules have a 16.368MHz XTAL instead of the standard 16MHz. This meant all hard coded register values based around 16MHz were off(FSKDEV, Frequency, AFSK tones, TXRATE)
Not sure if it's an issue in my code or not, but APRS transmission without a message is malformed and not accepted. It seems to be missing the last character. Location with message seems fine
APRS transmission without a message is malformed and not accepted
That's possible, I'm not sure whether I tested APRS transmission without a message.
A quick word of encouragement on your AX5043 development I am a member of the Association of Model Submariners and using an AX5043 with an Arduino at 27Mhz for radio control would be most useful for modellers worldwide. (27 MHz penetrates water well.) Some background and our attempts so far: https://www.theassociationofmodelsubmariners.com/ https://github.com/rdforrest/27MHz-using-AX5043
@rdforrest very cool! The low frequency range AX5043 can achieve is one of its most interesting features.
This got put on the backburner for a bit, but not dropped. I finally have a way to confirm the radio is doing what I intend.
@rdforrest what's funny is I'm using this module for model rocket telemetry. So in the end it will be used for both high altitude and submarine vehicles.
Hoping to get RX working in the next few weeks
@iangoegebuer actually ... I also started working on this, seeing as there was no progress. I will publish my updates on a separate branch later today.
EDIT: Added in the referenced commit
@jgromes sounds good. I'll see about porting mine over into your commit.
What development board are you using?
I pulled your code and got it mostly working with my AX5043 board.
A couple of notes from getting it working:
We will have 3 different board crystal frequencies to deal with including all the math around that. 26Mhz, 16Mhz and 16.368Mhz
Bitrate and frequency deviation values need an extra / 1000 to account for Mhz vs Khz values.
Just a heads up that AX5x4x lines are EOL
https://www.onsemi.com/pcn/public/final-document/cC_a6TSDEaHm6sPgH1emKA
We will have 3 different board crystal frequencies
I was hoping to get away with just one ... we will need a better way to provide no-default frequency, currently it's just a macro.
Just a heads up that AX5x4x lines are EOL
I'm aware of it - the chip was so good they had to kill it to give everyone else a chance, I suppose. Unfortunately there seems to be no replacement. Still, I'm going to finish this, there is still some supply left.
I was hoping to get away with just one ... we will need a better way to provide no-default frequency, currently it's just a macro
I have a solution. I'll push it tomorrow, just cleaning up my hacks first. Essentially a protected variable in the ax5x43 class that can be overridden at init time. It works and I was able to send an AFSK packet.
My dev board uses different configs as well. Like the clock divider and such.
I have pushed what I have so far, see the attached commit. I get a transmission, no promises that it's the intended data yet
There's a promise of valid data with the latest push to my fork. It has successfully talked out and been logged go aprs.fi!
Will start poking at receive soon.
@iangoegebuer thanks, however, I think we should also take a moment to consider how the existing AFSK should be integrated with AX5x43, so that AX5x43 can seamlessly support all the protocols and modes already covered by the current AFSK implementation.