-
Notifications
You must be signed in to change notification settings - Fork 32
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
radio.receive_full() #29
Comments
Hi Stefan, Great to hear you are putting Bitio to good use in your school, sounds fab! The radio feature was contributed by another user, so I just accepted the pull request, handy thing that! I've got to put some work into Bitio soon to support the new V2 features just released, and I am dreaming up a sort of 'auto detecting' api.py. Really, bitio on the micro:bit end is just MicroPython (with an image display on start to improve the user experience). All the heavy lifting is done at the PC end - api.py drives the MicroPython remotely by sending a thing called a Raw REPL command (basically like typing at the keyboard, but it has a deterministic result sequence for all normal and error cases). If you make a list of the features you could usefully use in your school (add them to this issue) I will bump them up the list for you. |
Thanks for response. Exciting to see a new version of the micro:bit coming out. I think the auto-api idea you detailed sounds good. I spent some more time digging tonight, as I felt slightly inept given my failure to add a method wrapper for radio.receive_full(). Also I noticed a conversation in issues about updating MicroPython in the .hex file, but that you were not ready to do that given it may impact your textbook examples. Is bitio still using 0.9? It looks like .receive_full() function wasn't part of the initial radio module code, so that would explain why my wrapper gave a "no attribute 'receive_full'" error. If that is the case, I guess I may have to be patient with this one particular feature and focus on some other activities in the meantime. I'll think on what features might be most beneficial to us. Without set_pixel() and get_pixel() we've often implemented something similar as a class as many students want to design games with control over a pixel character. I tried adding in set_pixel() to api.py tonight and it seemed to work reliably, but I struggled a bit with get_pixel() as it was returning None consistently. |
Stefan, I have been linking any projects I find on to the front README page - if you have any code in github that uses bitio, please share a link here and I will link out to your project. |
@stefan-scott Just FYI, there is a new version of bitio.hex on this branch: https://github.com/whaleygeek/bitio/tree/newarch that is confirmed working on a V2 micro:bit as well. I have written a simpler radio.py tester as well, and also in for_microbit/receiver.py a demo receiver end that you can communicate with by sending from the host via bitio. Current fun game is having 20 micro:bits all running the receiver.py, and doing a single send from the PC/bitio host end and seeing all 20 displays flash in sync! Have fun. |
@stefan-scott Oh, ps the newer bitio.hex on the other branch will of course have receive_full baked inside it, so you might want to re-try your API addition again and see if you can get it to work. If it works, please do send a pull request so I can include your new method in the core code for others to use, thanks! |
I was really happy to see the addition of some radio functionality this fall. I'm a high school educator from Canada and we've been using your library with our introductory CS classes for several years now. I've been working on developing some radio-based activities for the students and became interested in distance detection / object triangulation by looking at the signal strength of received messages with radio.receive_full()
However, it appears that hasn't been implemented yet into api.py. I've spent some time looking through the library files in hopes that I might be able to work on this feature. Am I right in understanding that the actual code of the radio functions isn't in any of the .py files in the library, but on the micropython that is on the micro:bit?
Does this mean if I want to work on this (or at least see the inner workings of how the radio commands are processed) that I need to see the source code of the microbit micropython? The supplied hex file still uses the same micropython as the mu editor? (the link on the main bitio README is broken, but that looks like where it was originally leading to)
The text was updated successfully, but these errors were encountered: