search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.87k stars 0 forks source link

Not really an issue: what about the planned changes #46

Closed daniwebCH closed 8 years ago

daniwebCH commented 8 years ago

Could somebody tell me what are the planned changes and schedule for future versions?

A) Is there a plan to make the stack part less encapsulated to the current code (a clearer OS Abstraction layer)? B) Is there the plan to support the STM32L051Cx CPU ?

PS: Is there a place where to put those questions? Thanks

mluis1 commented 8 years ago

The project schedule is mainly dependent on LoRaWAN specification updates releases.

Currently we can say that:

To answer your questions: A) If you think that the APIs aren't well defined or clear enough, could you please indicate what you would like to see improved? If possible please provide examples.

Currently the only requirements to run the LoRaWAN MAC layer is to have a radio driver as well as a way to schedule specific tasks (software defined timers). It is our intention to transform the LoRaWAN specific code into a stand alone library. But, for the moment it isn't the highest priority task. On mbed you can already find a LoRaWAN library example (LoRaWAN-lib). This example is synchronized with this project every time a new release is done. There are also 2 projects that show how to use this library LoRaWAN-demo-72 and LoRaWAN-demo-76

B) Yes, there is a plan to support the STM32L051Cx CPU. One of the main reasons to update the STM32 drivers library is to include the support of these microcontrollers.

You can always send your questions comments to support_rf@semtech.com

x893 commented 8 years ago

Hi, Currently lora_pkt_fwd exit if no SX1301, may be better notify server (in report for example) about this error. I make this modifications and can see gateway status remotely.

mluis1 commented 8 years ago

@x893 I guess you posted your comment in the wrong repository. It should be posted on Lora-net/packet_forwarder isn't it?

x893 commented 8 years ago

yes - my mistake

daniwebCH commented 8 years ago

Hi Miguel,

thanks that you took time to answer.

A) As far as I saw the needed drivers by LoRaWAN MAC layer are radio, timer and utilities. In addition the radio uses: delay, timer, spi and gpio . Back to my original remark ;-) , I was thinking a bit more regarding this and your remark mentioning the idea (not first priority) to make a library was part of the answer of the step i missed.

For example currently the timer.c/.h do not have only the functionality to provide software timers, but also to:

Regarding gpio.c/h I would remove the IOE part.

This code as far as I understood has been started as example with an application, I find somehow normal that the split between all the needed parts of the stack is not perfect (and what means perfect, this can never be as long as in code there are parts related to matter of taste of developers). The small suggestions I made are more pertinent from the moment when you will have the time to isolate the code on the direction as a library.

B) I see in conjunction of porting to STM32 HAL that it will be more "easier" to port/use it with a different cpu and cpu family. Good news, do you have an idea about when will this happens on the github?

PS: on this case if I would have suggestions like changing a name of the define LORAWAN_DUTYCYCLE_ON to LORAWAN_DUTYCYCLE_IS_ON I should send it to support_rf@semtech.com mailto:support_rf@semtech.com? The reason is that when LORAWAN_DUTYCYCLE_ON is used I do not know (without looking the definition) if for example also a LORAWAN_DUTYCYCLE_OFF is existing. When I seee the codeLoRaMacTestSetDutyCycleOn( LORAWAN_DUTYCYCLE_ON ); I would expect that it is set to ON and no need to check where it is defined. When I seee the codeLoRaMacTestSetDutyCycleOn( LORAWAN_DUTYCYCLE_IS_ON ); I would expect that I have to look the contents of the define

Thanks Daniele

Le 22.02.2016 13:43, Miguel Luis a écrit :

The project schedule is mainly dependent on LoRaWAN specification updates releases.

Currently we can say that:

  • Time to time there will be maintenance releases. The goal of these releases is to provide corrections to the issues reported on GitHub as well as issues reported by other channels.
  • The next major release should include the first implementation of the Class B end-devices.
  • We are also currently working on updating the STM32 StdPeriph_Drivers(deprecated) to the new STM32 HAL drivers. New STM32 microcontrollers are only supported by these new drivers.

To answer your questions: A) If you think that the APIs aren't well defined or clear enough, could you please indicate what you would like to see improved? If possible please provide examples.

Currently the only requirements to run the LoRaWAN MAC layer is to have a radio driver as well as a way to schedule specific tasks (software defined timers). It is our intention to transform the LoRaWAN specific code into a stand alone library. But, for the moment it isn't the highest priority task. On mbed you can already find a LoRaWAN library example (LoRaWAN-lib https://developer.mbed.org/teams/Semtech/code/LoRaWAN-lib/). This example is synchronized with this project every time a new release is done. There are also 2 projects that show how to use this library LoRaWAN-demo-72 https://developer.mbed.org/teams/Semtech/code/LoRaWAN-demo-72/ and LoRaWAN-demo-76 https://developer.mbed.org/teams/Semtech/code/LoRaWAN-demo-76/

B) Yes, there is a plan to support the STM32L051Cx CPU. One of the main reasons to update the STM32 drivers library is to include the support of these microcontrollers.

You can always send your questions comments to support_rf@semtech.com mailto:support_rf@semtech.com

— Reply to this email directly or view it on GitHub https://github.com/Lora-net/LoRaMac-node/issues/46#issuecomment-187156132.

mluis1 commented 8 years ago

Thanks for the feedback. We will try to take in account all your comments in future releases.

Please note that the Timers implementation are currently being updated due to the move to the new STM32 HAL library. So, in the future we will have only RTC driver available.

Concerning the current RTC implementation (as well as future implementation for STM32L1xx mcus.) The RTC is accelerated because on STM32L1xx there is no way to access the subseconds value. (On STM32L0xx there is a way to access the subseconds value.) The acceleration of the RTC just impacts a little bit the power consumption by 1 or 2 uA and reduces the time you can be in sleep mode.