Add RAK7391 + RAK13300 WisBlock radio presets (slots A & B)

[Kodo-kakaku]

Changes

• radio-settings.json: new entries rak13300-slot-A and rak13300-slot-B.

Hardware mapping

Slot	SPI device	bus_id / cs_id	Control lines (IO expander line offsets)
A	/dev/spidev0.0	0 / 0	Reset=4, Busy=5, IRQ=6
B	/dev/spidev0.1	0 / 1	Reset=12, Busy=13, IRQ=14

• cs_pin: -1 (hardware chip select)
• use_gpiod_backend: true (GPIO via character device; IRQ path uses polling where applicable)
• gpio_chip: Linux gpiochip index for the expander — must match /dev/gpiochipN (confirm with gpioinfo / docs)
• use_dio3_tcxo / dio3_tcxo_voltage: typical RAK13300 SX1262 + TCXO usage

Notes

Slot B uses a different SPI chip select and different reset/busy/IRQ lines than slot A. Drafts that reused slot A pins for slot B are incorrect for this hardware.

Testing

• RAK7391 + RAK13300 in slot A
• RAK7391 + RAK13300 in slot B

Links:
RAK13300
RAK7391

[rightup]

Wow this is exciting! Has this been test and working in a live environment ?

do you mind popping into this branch, thanks

[Kodo-kakaku]

Hello @rightup !
First, I'd like to thank you for your contribution to MeshCore development. Regarding your question, I've launched two modules in different Docker containers from the feat/newRadios branch, and they work quite well. I can't evaluate the completeness of the solution because my base station isn't visible on the overall project map. I didn't quite understand difference between the feat/newRadios branch and feat/companion branch. Initially, I thought feat/companion branch was related to clients, and I didn't study it because navigating around the city with my solution is quite problematic)))

Module A:

Module B:

Device:

Could you please tell me what is required of me to resolve the branch conflict and how else I could contribute to the project?
Thank you!