LoRa WAN US915 Support #603
Conversation
Adds a driver for us 915 protocol to the lora WAN drivers.
fix lora us915 logic to step into 500 kHz range
|
@deadprogram should be good to go now, sorry I didn't get to test it. I got food poisoning 💀 |
|
Note that because this re-structures the implementation of this driver, it will be breaking for #535 |
|
Here is an example where changing to |
|
The most straightforward solution to the TinyGlobo example within how this PR works, would be to provide Example: func (c *ChannelAU) SetFrequency(freq uint32) error {
c.frequency = freq
return nil
}There is some duplication of code, but it would allow for validation to be added at some point. What do you think @mirackara @iamemilio ? |
|
I like that. It feels like a much safer way to handle this data structure. |
|
@iamemilio can you add to this PR please? 😸 |
| @@ -7,27 +7,56 @@ const ( | |||
| AU915_DEFAULT_TX_POWER_DBM = 20 | |||
| ) | |||
|
|
|||
| type ChannelAU struct { | |||
There was a problem hiding this comment.
This looks like identical code for all ChannelXX types-
Should we have a base channel type and compose these "higher" level types with it?
There was a problem hiding this comment.
ie:
type channel struct {
frequency uint32
bandwidth uint8
spreadingFactor uint8
codingRate uint8
preambleLength uint16
txPowerDBm int8
}
// Implement methods for channel here...
type ChannelAU struct {
channel // Exposes exported channel methods.
}
There was a problem hiding this comment.
@soypat that sounds like an excellent refactoring for a subsequent PR.
There was a problem hiding this comment.
I will submit a PR that does exactly this later on...
|
Forgot to mention that I tested this in EU868 and it still works. As long as the US915 region is working, then I suggest we merge and then can do some additional refactoring from there. |
|
Commits picked up in #611 so now closing this PR. Thank you very much everyone! |
Adds a driver for us 915 protocol to the lora WAN drivers.