Class C support? #208
Comments
|
Class C support: I've looked at this, but I have not had time to test. It's not hard; we just have to restart the receiver immediately on each RX (or TX) complete event; and then we may have to put class C awareness in a couple of places. If you want to experiment, I can probably tell you where to add hacks in a couple of places. However it would be very experimental, which might not be something you want to get into. It's definitely plowing new ground. |
|
@terrillmoore voice and looks awesome!, we have been working its been long time.. because of not possible the class-C, we passed away free lora, we crypt with our techniques and not joining any lora network, if you can help us, it will be milestone for us, because our city will be smart and i would love built it together :) elements has their energy so they need to communicate instantly so thanks so much for help and co op^^ |
|
Kind of busy the next few days, but will see what can be done. Please confirm that you want to implement LoRaWAN type C (device <> gateway) -- this code won't support device <> device conveniently. |
|
@terrillmoore you are a super hero without a cape! absolutly right, Gateway to nodes, and maybe nodes to gateway i can't wait updates ! thanks |
|
had progress with working in class C? |
|
Hi @schwiderke92 -- the Raspberry Pi driver release https://pi64.win has distracted me a bit. Also, I really want to get port 224 working so we can start testing for LoRaWAN compliance, and I'm debating whether I should make any other changes before doing that. But I'll think more about it. It may be a few weeks. |
|
OK. I have to implement class C functions and I really like LMIC, I'll test other functions and I'll come back when it's implemented. |
|
Hi again @schwiderke92, thought I'd give you an update. Based on the work for #215, Class C is not quite as easy as I thought. I am going to try to finish up the bulk of the regression testing and compliance testing for Class A first. The big issue with Class C is that receives can happen at any time, and this makes for interesting side-effects with the update logic and the interactions with your application. I think compliance testing for US915 will take another few weeks, depending on my other tasks. |
|
Dear @terrillmoore, its so great news! been several weeks, i have been this exciting news! i would so happy if i get experinces and suggestions from you Mr Terry. please mail [email protected].. Class C will change the rules and society on AI based smart cities |
|
Hi. Has there been an update? |
|
@schwiderke92 waiting updates from @terrillmoore |
|
any update? |
|
Sorry to say, nothing yet. See comment in #362. Class C is high on the list. |
|
@terrillmoore its been six months to you call us its near, WHY IS IT STILL WAITING? |
|
Sorry you're upset. This is an unfunded project, basically a volunteer effort. All I can do is the best I can. I've tried to be public about the priorities -- data integrity in Class A and existing applications has been taking priority over new features. I have many other responsibilities, and not much control (or predictability) on the demands on my time. But to make a response that could lead in a constructive direction: please see if you can get someone to contribute a pull request. |
|
I've been trying to enable Class C without success bu tI'm willing to perseverate ;-). Apart from calling os_radio(RADIO_RX) or radioRx() from EV_TXCOMPLETE, what else should be done? LMIC.dataLen stays invariantly on 0. Edited: |
|
Hi, any update?? i run LMIC on SAMR34 in Class A and i need Class C. please!!?? |
|
@FedericoAndrades still waiting updates from @terrillmoore |
|
I'm sure that everyone has lost patience with me.... but I've started work on this. I hope to commit something next week. I have already updated the state diagrams and identified the code to be written. Look for pushes to new branch issue208; I probably won't push intermediate code but will probably push docs. |
This is a breaking change, because clients previously could use `LMIC.rxtime` to schedule a receive. This no longer works; `LMIC.nextRxTime` is used to schedule the receive, and now `LMIC.rxtime` only is used to report the time of last receive. But in addition, this adds a new configuration variable, `LMIC_ENABLE_class_c`, a new API for run-time enabling (if configured in), and support for starting class C receives at the appropriate times. This seemed to require an additional receive buffer, to avoid collisions; and therefore client code that depends on results showing up in LMIC.frame[] may be rudely surprised.
This is a breaking change, because clients previously could use `LMIC.rxtime` to schedule a receive. This no longer works; `LMIC.nextRxTime` is used to schedule the receive, and now `LMIC.rxtime` only is used to report the time of last receive. But in addition, this adds a new configuration variable, `LMIC_ENABLE_class_c`, a new API for run-time enabling (if configured in), and support for starting class C receives at the appropriate times. This seemed to require an additional receive buffer, to avoid collisions; and therefore client code that depends on results showing up in LMIC.frame[] may be rudely surprised.
This is a breaking change, because clients previously could use `LMIC.rxtime` to schedule a receive. This no longer works; `LMIC.nextRxTime` is used to schedule the receive, and now `LMIC.rxtime` only is used to report the time of last receive. But in addition, this adds a new configuration variable, `LMIC_ENABLE_class_c`, a new API for run-time enabling (if configured in), and support for starting class C receives at the appropriate times. This seemed to require an additional receive buffer, to avoid collisions; and therefore client code that depends on results showing up in LMIC.frame[] may be rudely surprised. os_radio(RADIO_RST) now inserts a 1ms delay to allow the radio to recover.
|
@terrillmoore Thank you for your work on this project. I am also interested in using this library with a Class C device and was curious about how that area of development has been going. I see your recent commits to the issue208 branch and it appears that all todos are checked off but a few open questions are still listed at the bottom. How is this going? |
|
It passed Class A testing, but failed Class C testing in an ugly, hard to fix, way. This made me think that a more radical approach is needed. The implementation in issue208 uses even more state flags to steer control around in the existing code, rather than reengineering the LMIC as one or more explicit FSMs. In a clean design, there would be a radio FSM (so that it could independently turn on receives), and a MAC FSM. It was clear that it would take more time than I had available to either (a) debug the existing approach or (b) refactor the LMIC into a more robust approach. Meanwhile, I had other commitments, so The Things Network NY did our class C prototyping using the RN2903 with the latest firmware. This allowed us to prove concept with NYC Mesh, using LoRaWAN as an administrative network for their dispersed metro-area Wi-Fi network), but as a consequence, last six weeks of spare time were spent on that. [See the brige github repository for an artifact of this effort.] Conclusion: it's probably going to be a few months more before this materializes. |
|
@terrillmoore class c ready? |
i am plant it in street lights, so i need instant message with otherts continusly, so your repo support Class-C?
The text was updated successfully, but these errors were encountered: