433 initial work

[jlpoltrack]

Work for EU 433 & US 70 CM HAM frequency bands.

[olliw42]

@jlpoltrack if I want to test this, I think I can mis-use my E22-900 modules, right, or would you see a reason it would not work (not talking about suboptimal RF performance with wrong antenna and RF backends)

[jlpoltrack]

Re: if I want to test this, I think I can mis-use my E22-900 modules, right, or would you see a reason it would not work (not talking about suboptimal RF performance with wrong antenna and RF backends)

As far as I can see the SX1268 (which E22-400 uses) doesn't support as many frequencies (so it is probably cheaper):

SX 1268 | 410 to 810 MHz:

SX1262 | 150 to 960 MHz:

[olliw42]

so, my E22-900 which use the sx1262 should allow me to at least run the code, right didn't know the E22-400 uses a sx1268, thx for clarifying

btw, if you want to put down a reference/cite, just add a '>' in front, like '> kasfhashfdkuh' gives

kasfhashfdkuh

[jlpoltrack]

btw, if you want to put down a reference/cite, just add a '>' in front, like '> kasfhashfdkuh' gives

Good tip :)

[olliw42]

pl go through mLRS/Common/fhss.h again, it still has a number of 70_CM_HAM vs 70_cm_ham issues (and it is probably not compiling as is)

in fhss.h, at around line 32, you probably want to add something handling 70

[jlpoltrack]

Upper / lower fixes, definition added on 32, ifndef fix. Does at least compile for me with new freqs enabled:

[olliw42]

@jlpoltrack with the suggested changes, I tried it on my system, but unfortunately it crashes it when I select e.g. 70 ... I guess the 900 modules don't like being used at 400 ...

so, we can't do as I first suggested, i.e., that I PR and then add on top what it needs else ... we need to rely on you to test this PR

[olliw42]

@jlpoltrack have you "Allow edits from maintainers.” enabled? I tried to push changes to your pr, but it complains that I don't have the access rights

[jlpoltrack]

with the suggested changes, I tried it on my system, but unfortunately it crashes it when I select e.g. 70 ... I guess the 900 modules don't like being used at 400 ...

so, we can't do as I first suggested, i.e., that I PR and then add on top what it needs else ... we need to rely on you to test this PR

Bummer - just an FYI, my current hardware config is G441 + E22 which doesn't have a tx config (just rx). I will check out the datasheet to see if there's any difference for these bands.

have you "Allow edits from maintainers.” enabled?

Looks like it (FYI, I haven't changed this setting):

[geofrancis]

Could you expand this to include 458.5 to 459.5 so its legal in the UK?

https://www.largemodelassociation.com/resources/legal-model-frequencies-in-uk/

[olliw42]

Looks like it (FYI, I haven't changed this setting):

something mist be bad on my side ... now I cannot even pull anymore without a access denied error ... git/github sometimes is simply really a pain ... I guess I need to do it stupidly and download LOL ... grrrr

[jlpoltrack]

@geofrancis

Could you expand this to include 458.5 to 459.5 so its legal in the UK?

Can look at after getting 433 and 70 cm working on E22. Quick note is that 1 MHz is awfully small (especially as mLRS uses 500 KHz bandwidth). 2 channels with 1 for bind and 1 for connection?

[olliw42]

@jlpoltrack this is super nasty, I'm sorry, but as said I can't ven pull anymore so here the files with changes as .zip mlrs-pr52-4jlpoltrack.zip play them into your branch, and commit

as regards why 400/70 didn't work for me. One for sure will need to do some code changes in the driver in order to activate the LF instead of the HF part. Maybe this woudl be already what it would need.

[olliw42]

deleted as obsolete :D:D

[jlpoltrack]

Alright, I did this (and put the files in the correct folders - all good)

this is super nasty, I'm sorry, but as said I can't ven pull anymore

Did your SSH expire?

as regards why 400/70 didn't work for me. One for sure will need to do some code changes in the driver in order to activate the LF instead of the HF part.

I think this is SX127x specific? Continuing to look at SX126x datasheet.

[olliw42]

great!!!

I think I can't see anything anymore. I had this tested in as much as I could see the options in the cli, see them in the lua, and change them thorugh the lua (to get the modules crashing).

not sure how to proceed from here. As is it is probably not functional, since it may need some changes in the sx driver, or where ever else. I could merge, based on that it won't do anything fior the existing targets. On the other hand, merging code which hasn't been demonstrated to work isn't the textbook approach. What would be your suggestion?

[olliw42]

Did your SSH expire?

I'm not using SSH ... SSH is way above my paygrade ;)

I think this is SX127x specific? Continuing to look at SX126x datasheet.

you are probably be correct. Just pulled something out of my head. Good thing is you have some hardware to test :)

[jlpoltrack]

How about this:

• Could you provide some hints on how to create a Tx target for G441 + E22 (I can do the HAL file)? I think it makes sense to see if I can get the tx working without crashing before doing anything else. Crashing means CLI / Lua becomes unresponsive?
• If that works, I need to build another copy of the hardware (have parts just need to solder) to test out rx side
• Worst case, I've got some E77-400 on order (for use with easy-solder board) so can isolate my hardware if that is the problem.

[olliw42]

it's also a g441kb, like the rx ones? 8 MHz ceramic crystal likes these, right?

[jlpoltrack]

Yes, G441KB and 8 MHz resonator, no point in reinventing :) but have different pin assignments for the E22.

Here's the schematic FYI (yes, UART2 is messed up, should be PB3 and PB4)

1W Experiments.pdf

[olliw42]

what I could do is to make tx target of the rx-diy-e22-g441kb, as I have that hardware and so could even test from here it should be asy to dapt the hal, I would think (I actually wonder if I should do a g431kb ... I believe 441 or 431 should not matter - unless that extra pheripheral is needed - would make it mroe general/generic)

[jlpoltrack]

Tx target works for me.

(I actually wonder if I should do a g431kb ... I believe 441 or 431 should not matter - unless that extra pheripheral is needed - would make it mroe general/generic)

Do you mean G431 code could be used on G441? If so, that makes sense (mLRS doesn't use the hardware AES). I guess at some point there will be hardware standardization...

[jlpoltrack]

I'm looking at other LoRa libraries and one thing that I see done is 'Image Calibration' Section 9.2.1. For SX1262 it is default for 902-928 MHz (maybe 868 is close enough but 430 too far away)?

It's available in the mLRS driver:

https://github.com/olliw42/sx12xx-lib/blob/c6bcf11aeb7186cebcca74b54a1a9f6f99d36433/src/sx126x.h#L72 https://github.com/olliw42/sx12xx-lib/blob/c6bcf11aeb7186cebcca74b54a1a9f6f99d36433/src/sx126x.h#L441

I think 0x6B to 0x71 would be around 430 to 450 MHz.

430 = 0x6B = 107 440 = 0x6F = 111 470 = 0x75 = 117

440 to 470:

30 MHz | 6 steps = 5 MHz / step

430 to 440:

10 MHz | 4 steps = 2.5MHz / step?

[olliw42]

@jlpoltrack you should find a tx E22 G431KB target now in main I in fact didn't had such a board with E22 but only the E28 variant of it, which is hardware wise however equal except of E28 vs E22, and it works even though it has a g441kb soldered in should hopefully serve you as template for your board

[jlpoltrack]

Thanks very much!

Unfortunately, it seems to crash - no LEDs.

My edits were:

• Enable 70 cm in device_conf.h, disable 868,915
• Update the HAL pinouts and power settings, commented out some stuff that probably didn't need commenting

Checked:

• Power rails look okay
• 8MHz clock looks okay
• Reset on both MCU and SX is high

Attaching my HAL as well if you want to see if I got anything very wrong. tx-hal-diy-e22-g431kb.zip

[olliw42]

it does crash also if you don't do any sx stuff? I too had the "same" sympthom, not even leds, so I wonder, may it gets stuck somewhere else (you may have noticed that there are a number of while(1){}, each can be a reason), and not in the sx section I guess I would first try to establish that the leds can blink, and that the dbg uart works, once you have a dbg uart, you can add puts and see there it crashes

[jlpoltrack]

I can blink the LEDs with other code setup to use the clock config from the project, so I think that at least works.

Any steps for enabling debug other than:

Comment out this block: https://github.com/olliw42/mLRS/blob/main/mLRS/Common/hal/tx-hal-diy-e22-g431kb.h#L19 Set UARTC to UARTF: https://github.com/olliw42/mLRS/blob/main/mLRS/Common/hal/tx-hal-diy-e22-g431kb.h#L50

I guess it gets stuck early on, even if I comment out both sx lines in mlrs-tx.cpp I still get no LEDs. https://github.com/olliw42/mLRS/blob/main/mLRS/CommonTx/mlrs-tx.cpp#L146

[jlpoltrack]

Well the hardware works :) but I don't have any leads as to why the 433 code doesn't work. I was rude and put the 70 cm HAM freqs into the 868 fhss list for the current master (9ca32bd) and setup the device to only use 868 (which had the 70 cm HAM freqs):

[olliw42]

yeah, it seems we have a simple bug somewehere ... I came to this concuion in the meantime too ... will look at it

[jlpoltrack]

Really appreciate all your help on this, I will continue to poke around and let you know if I find anything. Well not exactly 1 Watt - maybe I need to get an attenuator for the RF meter (or complain to eByte):

[jlpoltrack]

Is there some threshold for minimum number of channels elsewhere? On Master branch:

• 3 channels of 433 I get stuck - red LED only
• 6 channels of 433 I get stuck - red LED only
• 10 channels (same as 868) works okay

[olliw42]

the accuracy of this meter is just 1dBm or so, and it's easy to get insertion losses of 0.5-1dB ... a 29 would have been nice though LOL

[jlpoltrack]

Built up another board for receiver and was able to bind! Couldn't figure out how to get the out working so just disabled. Close and yet far away :) Haven't measured power consumption but looks like the gain of the amplifier is something like 10-12db so you can run really low power while testing.

[olliw42]

oh man ... 1.5 h later ... see the comments

my units are now working, supposedly at 70 cm ... (and btw putting some dbg.puts() did the trick LOL)

[jlpoltrack]

Many, many thanks. :)

Did you run into the issue with 433 EU Bands hanging?

Last one one from me - I want to have out and only use 2 uarts, so in the HAL I have (all other UART stuff commented out):

'uart_setprotocol' not declared?

If I change to UART2 it compiles?

[olliw42]

Did you run into the issue with 433 EU Bands hanging?

I haven't tried 433 yet, only 70 cm

Last one one from me

maybe before doing it fancy, could you pl make a simple test case, and confirm that it now works with 70 cm, and that you do get a good connection, can use the lua, etc ??

[olliw42]

'uart_setprotocol' not declared?

yes, that's not yet declared for LPUART1 see https://github.com/olliw42/stm32ll-lib/blob/main/src/stdstm32-uart.h#L577-L578

I hadn't the time yet ... I'm just a human :)

[olliw42]

can you pl also rebase onto main, I pushed few things

[jlpoltrack]

Resolved conflicts (new to me) let me know if I missed anything.

[jlpoltrack]

For testing - can you give me some hints on getting away with just 2 UARTs (one with JR Pin 5) due to my hardware bug?

• If I try to just have UART + UARTC w/ define JR Pin 5 only, compiler complains about UARTB
• If I try to just have UART + UARTB w/ define JR Pin 5 only, compiler complains about UARTC

[olliw42]

concerning the 433 MHz issue: in fhss.cpp line 73, https://github.com/olliw42/mLRS/blob/main/mLRS/Common/fhss.cpp#L73, you need to write

if ((config_i != FHSS_CONFIG_433_MHZ) && (k > 0)) {

we probably will ned to change this to something more clever, but for the moment it does the trick

[olliw42]

not sure I understand your 2 uarts issue 2 uarts should be fine, right? one for serial, one for jrpin5 or out in principle you only would need one uart...

you MUST not fool with UART or UARTB or UARTC, all you can change is the part after the USE, like UARTB_USE_UART1, UARTB_USE_UART2, UARTB_USE_UART3, etc

for tx the associated has to strictly be as written: // UARTB = serial port // UARTC = COM (CLI) // UARTD = serial2 BT/ESP port // UART = JR bay pin5 // UARTE = in port, SBus or whatever

[olliw42]

what is the hardware bug again? just looked into your schematics, and I can't really see a bug ... is it that you think uart2 cannot be on PA15? the tx-hal-diy-e22-g431kb.h which was added for you should give you the idea of how to do this

[jlpoltrack]

Let me provide some more details, I'm a little further but having issues with CRSF / JR5 using this branch.

• Want to use UART1 PA9,PA10 for JR5 w/ R-D network
• Want to use UART2_REMAPPED2 PB3, PA15 for Serial (PA15 is wrong but can be changed as you note, I guess this is a G4 feature)
• Want to use LPUART1 PA2, PA3 for CLI

Only define is for JR5, in the HAL I've got:

• UARTB > UART_USE_UART2_REMAPPED2, with the RX_IO line (PB3, PA15)
• UARTC > LPUART1 (PA2, PA3)
• UART > UART1 (PA9,PA10)
• UARTE & UARTF are there (I assume they are ignored)

The CLI works over LPUART1 and I can change and store settings. I've made sure that I've got CRSF for 'tx ch source' but can't seem to get CRSF working. R-D network is in place as per the schematic.

HAL attached. tx-hal-diy-e22-g431kb.zip

[olliw42]

strange if you use a differnt uart (UART2, LPUART1) for jrpin5, then it works? I.e., is this uart1 specific, or generally doesn't work?

EDIT: ähm, you have noted this line in your hal??

#define UART_USE_RX_IO IO_PA15 // normally would be PB4!!

that's probably it ... one needs to be careful with the defines :)

[olliw42]

@geofrancis since we are getting quite close for this to be merged, let me come back to your suggestion of 458.5 to 459.5 as @jlpoltrack said, that's a bit tricky for mLRS, since it uses 500kHz bandwidth, and reserves at least one channel for binding, so that it would leave only one frequency. technically, there is no difficulty with that and no reason not to do that, but you wouldn't have any hopping at all

at this point I wonder how this works for other systems you may use in this frequency band. Maybe it would be better discussed in the rcgropups thread, or as a new issue in this repo.

I also wonder: isthis actually reasonable? I mean, isn't it that in the UK you also can use the 433 MHz band? (https://en.wikipedia.org/wiki/LPD433)

[jlpoltrack]

@olliw42 Thanks for your review of my HAL, too many copy and pastes :) Currently have CRSF + Lua working, can bind and change settings on both Tx and Rx. Today I will:

• See if I can get CRSF on a FC and verify MAVLink stream
• Fine tune the power config (really just for my setup I guess)

[olliw42]

FANTASTIC

ok, so I think this means that we can merge this PR. We do have now two people having it working in this range (you and me). What you indicate as missing are all not related to 433/70.

agree?

[jlpoltrack]

Works for me.

[geofrancis]

@geofrancis since we are getting quite close for this to be merged, let me come back to your suggestion of 458.5 to 459.5 as @jlpoltrack said, that's a bit tricky for mLRS, since it uses 500kHz bandwidth, and reserves at least one channel for binding, so that it would leave only one frequency. technically, there is no difficulty with that and no reason not to do that, but you wouldn't have any hopping at all

at this point I wonder how this works for other systems you may use in this frequency band. Maybe it would be better discussed in the rcgropups thread, or as a new issue in this repo.

I also wonder: isthis actually reasonable? I mean, isn't it that in the UK you also can use the 433 MHz band? (https://en.wikipedia.org/wiki/LPD433)

The lack of hopping isnt really a problem, but if its more work than just increasing the frequency range then dont worry about it. its not essential to anything im currently doing, I have good enough results with 868. It was for some friends of mine that use submarines, they really like low frequencies.

LPD433 is limited to 10mw so its not really that useful.