Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ST fw update for band selection at runtime #23

Merged
merged 3 commits into from
May 7, 2020

Conversation

giulcioffi
Copy link

The original version of the fw set the frequency region with a define. If the user had to change it, the firmware needed to be re-compiled and flashed with the new defined frequency.
In order to overcome these steps, the fw has been updated to store the region as a variable. The initial band is set to the European one. Whenever a different band is selected by the user, the Lora state machine is re-initialized and the desired band of frequency is enabled.

Command "+BAND" has been added to the predefined set of AT commands to perform the band update. MKRWAN library has been updated to support this command (arduino-libraries/MKRWAN#78).
The user can change the frequency region by using the funciton bool begin(lora_band band).

A simple test (https://github.com/giulcioffi/tests_MKRWAN) allows to continuously change the desired region, read back the frequency of the RX channel and compare it with the expected one.

giulcioffi and others added 3 commits April 27, 2020 12:48
Command "+BAND" added to the predefined set of AT commands. It allows to select the frequency band at runtime.
The initial band is set to the European one. If the user selects a different band, the Lora state machine is
re-initialized and the desired band of frequency is enabled.
In the compiler builIn options, the symbols of the frequency bands of all the regions are set to False.

An interactive test is available here: https://github.com/giulcioffi/tests_MKRWAN/blob/master/band_test.ino
It continuously asks the user to select a new region. After the user inserts one, the value of the frequency
on the RX channel is printed. In case this value is different from the one that should be set for that region,
an error message is displayed.
@sslupsky
Copy link

sslupsky commented May 7, 2020

Can we please add a couple long overdue things to this PR to help with power consumption? The mcu cannot be in a low power sleep state when the module attempts to send a response or downlink data. This issue is somewhat manageable in situations where the module responds immediately to an AT command from the mcu. However, there are a few situations where this cannot be addressed with the current firmware. First is for class B or C device downlinks where the downlink does not correspond to an uplink RX window. Second is where the response is not immediate, such as a join command.

I think these issues could be addressed in one of four ways:

  1. Implement the module "IRQ" from the module to the mcu. Activate the IRQ a short time before sending data from the module to the mcu. MCU firmware would need to configure the EIC to wake on interrupt. There would need to be approx 0.5ms delay between activating the IRQ and sending the data to allow time for the mcu to wake up. Perhaps this delay could be configurable with a new AT command.

  2. Alternatively, the module "IRQ" could work the other way from mcu to module as a "Clear to Send" function. So, the module only sends data to the mcu when the CTS is active. This way, the mcu can set CTS inactive during sleep to avoid the module sending data during mcu sleep periods. This has the potential of a race condition where the module senses CTS active and initiates the process to send data. Simultaneously, the mcu sets CTS inactive and goes to sleep. This race could be averted by also including a check on the module side that CTS remains active at the completion of the transmit.

  3. Implement a serial RX "wake" protocol. That is, toggle the RX pin and then wait a short time before sending serial data. The mcu firmware would require the capability of reconfiguring the RX pin to the EIC and then wake on interrupt when sleeping. When the interrupt is detected, the mcu firmware reconfigures the RX pin to the serial port so it can receive the data. There would need to be approx 0.5ms delay between toggling the RX pin and sending the data to allow time for the mcu to wake up. Perhaps this delay could be configurable with a new AT command. This solution has the advantage of leaving the IRQ function for another use.

  4. Alternative to 3, the RX pin is used to indicate a Request to Send and the mcu configures RX to the EIC. When the mcu detects the RTS or otherwise wants to receive data from the module, the mcu reconfigures the RX pin to the serial port and requests the data from the module.

I am prepared to help with this but require some feedback on the suggested solutions from @facchinm and @giulcioffi

@sslupsky
Copy link

sslupsky commented May 7, 2020

@facchinm Could you please merge these commits to the master-1.3.1 branch and I can pull them and test this out.

@facchinm
Copy link
Member

facchinm commented May 7, 2020

@sslupsky sure, this is a starting point with minimal functionality (just to test runtime band switching which is the functionality I need to test the most).
Any improvement is very welcome! I like the idea 1; feel free to implement it and I'll be glad to merge 🙂
I'm merging this in the meantime

@facchinm facchinm merged commit 70d0306 into arduino:master-1.3.1 May 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants