-
-
Notifications
You must be signed in to change notification settings - Fork 545
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
Question: Implementation of mac commands #4
Comments
Hi Ivaylo, Thanks for looking into the MAC commands already! I have to dig a little bit deeper into the MAC commands before I can give a full answer, but as far as I think, there are three types: 1) initiated by the node, 2) initiated by the network server (e.g. frequency related MAC commands, could be based on settings?), 3) initiated by the user (give me the battery power, through the api). I appreciate your help, but since some of the MAC commands are related to regions, I'm thinking about first implementing support for different ISM bands, or at least cleanup the currently hardcoded frequencies and put them a sane model that can be re-used for different ISM bands (e.g. by using different build flags, one could specify for which ISM band to compile). As well I have to think about how to model which MAC commands are sent as Next week Thursday I'm going to present this project to the local Go meetup here in Amsterdam. Until then I'll cleanup some loose ends, fix some bugs and work on my presentation. So probably the week after I'll be working on new features again 😄 |
Hi Orne, My implementation is almost ready and it seems to be working for most of the cases that I have tested (automatically and with my end-device). I have noticed though that there is some strange error when I was trying to send a couple of mac commands, when the bridge told me that it can not marshal an mac command that I did not sent. When I dug a little bit, I found that it calls |
Thanks for your feedback, I think I know what is going wrong! I haven't started yet on the MAC commands yet. I'm currently doing some refactoring work on all three of the projects:
After that has been completed I'll look into your issue! |
Here is my implementation of the mac commands. It still needs some work, but it works fine at least for some of the cases (new channel, duty cycle, dev status have been tested with an end-device). I think that I am not going to change much my implementation , so you can review it. I only want to add the possibility to send mac commands over |
1 similar comment
Here is my implementation of the mac commands. It still needs some work, but it works fine at least for some of the cases (new channel, duty cycle, dev status have been tested with an end-device). I think that I am not going to change much my implementation , so you can review it. I only want to add the possibility to send mac commands over |
I've had a quick look at the diff: https://github.com/brocaar/loraserver/compare/master...Acklio:mac-commands?expand=1 First of all, thanks for your efforts! However, the diff is huge. This makes it really hard to give good feedback and to shape it into a mergable state as it covers a lot of parts of the architecture. As well I'm a bit surprised by the amount of work that you already did. I would have preferred to discuss the right implementation and approach first. |
Actually when I started implementing this, it didn't seem as that much work, but after some time I realized this is not going to be the case. Anyway, it was to some extend interesting to write a little bit more Go code, as I am not very experienced with this language so for sure it was useful for me even only in this regard. For the architecture, I tried to be inspired by the existing code + my sense of good practices. Basically my idea was to have some entities that can be shown to network server administrators for managing mac commands and that those entities will provide a small interface for The other changes are maybe less significant - nodeSession can store custom attributes for data rates and delays for a particular end-device (loraserver.go had to be changed accordingly - the new send method), app.js knows how to retrieve and update the entities, nodes.html now has very ugly views for the actual visualization. The more important decisions from my point of view that I had to take were the methods that loraserver.go will access for mac commands manipulations and how/what to keep. Right now I keep the last sent set of mac commands + possibly their replies (if I have them) + mac commands to be sent (right now saved separately and sent only if the last mac commands that were sent are not the same or if we have not received a reply for them). I hope it will not be that difficult for me to change my modifications
So far I have tried to provide a global overview of the change + give some reasons why I implemented all that. Please feel free to provide more details how you would expect this feature to be implemented or to ask for more details, which will make a code review feasible (I do realize it is not easy to see the change and understand it). Also I would not mind at all if I need to make some additional changes (rebase the branch on the new master for example, refactor some things, etc). |
I rebased the mac-commands branch on the current master (it seems to me that you have finished with the moving/restructuring). It is still a huge diff, so if you need more explanations, please don't hesitate to let me know :) |
Thanks! I won't merge as-is, since I still have to think what the right flow is for each MAC command and I would like to break the implementation of MAC commands into pieces. However, I'll take it as an example and make modifications where needed. This weekend I'll attend IoT Olympics and will try to get some feedback from other people on this. |
I've started working on the MAC commands implementation. My idea is that the network-controller will be a component that is not part of LoRa Server and that LoRa Server provides various mqtt topics for communication. Outline of my idea: There will be a new NetworkController backend which is responsible for the following topics:
LoRa Server will just keep a queue of MAC commands to be transmitted, but does not implement any MAC command logic so it doesn't know what to do with each MAC command. Example flow:
What do you think? |
Hi Orne, This generally seems as a good plan which allows a great deal of flexibility. I have some small concerns, but maybe they are due to my misunderstanding and in any case I don't think they are very serious. Here they are:
All those questions could be resolved I think, I mention them here just to make sure they did not escape your attention. Otherwise this seems as a good way to go. My 2c :) |
Something for after the initial MAC command implementation: I'm planning to add an option to the API and web-interface to add proprietary MAC commands (0x80 to 0xFF range). Since all MAC commands are base64 encoded in the LoraServer <-> network-controller communication, I think the only thing needed to realise this is to configure a list of If you're interested, see the pull-request link below for code changes so far. Feel free to comment and give feedback! |
I still have not looked into your implementation, so I am replying only based on your comments and I will provide a second reply when I manage to take a look into the code.
Also the idea about proprietary MAC commands sounds very good to me 👍 |
I reviewed quickly the changes in for the mac commands and all looks good to me. Good job 👍 |
I've just tagged version 0.8.0 with MAC command support :-) |
Hi @brocaar , |
Hi Orne,
Yesterday I started looking into the MAC commands and here is how I imagine them to work (let me know if that seems OK to you).
LinkCheckReq
/LinkCheckAns
is somewhat clear (I think that we takelsnr
or 0 iflsnr
is negative and the number of times the packet was received and construct the answer).NewChannelReq
, but I guess it is not that crucial. The user will be able to see the answers to the last set of MAC commands through the web interface.I have already implemented the part for
LinkCheckReq
/LinkCheckAns
(as described above), but I was not able to test it today, soI will test it tomorrowI will test it as soon as my end device recovers from whatever happened to it and push it to my fork. Depending on our discussion I can implement the rest as well and make a pull request.What do you think about all that?
Thanks,
Ivaylo Petrov
The text was updated successfully, but these errors were encountered: