Shop OBEX P1 Docs P2 Docs Learn Events
microbit radio comms — Parallax Forums

microbit radio comms

I am now working on a project that uses two microbits that are using radio communication. I have some simple code, but not ready to post it.

The big problem that I am having is, I think, is a timing solution between the radio.send and the radio.receive(). When I get this settled then I will post.

Ray

Comments

  • RsadeikaRsadeika Posts: 3,837

    This particular microbit will be outside gathering info upon request. The light and sound are values, I will try to add some info too the values, as it pertains to the location.

    I am still working on the ther program.

    Ray

    # June 20, 2024
    # This micro:bit will be outside gathering info
    # upon requests.
    
    from microbit import *
    import radio
    
    radio.config(group=24)
    radio.on()
    sleep(1000)
    
    while True:
        # Reads outside temperature and displays
        display.clear()
        tf = (temperature() * 9 / 5 + 32.0)-13    
        temp_string=str(tf) + "F"
        send_string = ("Temp: " + str(tf))
        display.scroll(temp_string)
        # Get a signal
        token = radio.receive()
        if token is not None:
            sleep(150)
            if token == "temp":
                radio.send(str(send_string))
            if token == "sound":
                sound = microphone.sound_level()
                radio.send(str(sound))
            if token == "light":
                light = display.read_light_level()
                radio.send(str(light))
    
        sleep(3000)
    
  • RsadeikaRsadeika Posts: 3,837

    Below is untested code of a general concept program. I still have not worked out the timing issue between the two programs. This a manual edition of getting some values from the other microbit, just to see what is really occurring. the next step would be to automate the logging procedure of that data while still show a scroll of the local temperature.

    The hard part will be to add the gately RTC code, so I could have date and time added to the log file.

    Ray

    # m_b_master.py
    #
    
    from microbit import *
    import radio
    
    radio.config(group = 24)
    radio.on()
    
    uart.init(115200)
    
    
    def get_radio():
        radio.send("temp")    
        sleep(150)
        token = radio.receive()
        if token is not None:
            #sleep(250)
            print("Msg: ",token)
    
    def get_sound():
        #sound = microphone.current_event()
        #sound = microphone.current_value()
        #sound = microphone.sound_level()
        #print(str(sound))
        radio.send("sound")
        sleep(150)
        token2 = radio.receive()
        if token2 is not None:
            print("Msg: ",token2) 
    
    def get_light():
        #level = display.read_light_level()
        #print(str(level))
        radio.send("light")
        sleep(150)
        token3 = radio.receive()
        if token3 is not None:
            print("Msg: ",token3)
    
    
    
    
    while True:
        inbuff=""
        if uart.any():
            inbuff=uart.read().strip().decode()
            uart.write(">> ")
    # QUIT
            if inbuff == "quit":
                #f.close()
                print("Program has ended.")
                sys.exit()          
    
    # Get the temp        
        elif inbuff == "radiomsg":
                get_radio()
                uart.write(">> ")
    
    # Get the sound       
            elif inbuff == "getsound":
                get_sound()
                uart.write(">> ")
    
    # Get the light        
            elif inbuff == "getlight":
                get_light()
                uart.write(">> ")
    
    
        else:
               uart.write("???") 
               uart.write("\n>> ") 
    
    
    sleep(100)
    
  • RsadeikaRsadeika Posts: 3,837

    The problem that I am seeing is, in m_b_master, when I request a value (temp,sound,light), sometimes I get a value and most of the time I get nothing. I think it is a timing problem, but not sure how to resolve this.

    Now I am thinking that on the module that is sending the requested value, maybe I should set that up as a separate task. So, basically I would have two tasks running, one task that handles the requests and the other task would handle the scrolling. I am not sure if the microbit can do this correctly. I also want to add some of the other sensor data to the request list.

    Ray

  • dgatelydgately Posts: 1,630

    @Rsadeika said:
    The problem that I am seeing is, in m_b_master, when I request a value (temp,sound,light), sometimes I get a value and most of the time I get nothing. I think it is a timing problem, but not sure how to resolve this.

    I could be mistaken, but I think that in the "Get the temp" code, the value of inbuff will always be empty... Tabbing/spacing is crucial in micropython. That section of code needs an additional TAB or spacing, aligning it to the "if inbuff" above it.

    while True:
        inbuff=""
        if uart.any():
            inbuff=uart.read().strip().decode()
            uart.write(">> ")
    
    # QUIT
            if inbuff == "quit":
                #f.close()
                print("Program has ended.")
                sys.exit()          
    
    # Get the temp        
        elif inbuff == "radiomsg": #<==  this needs to align with the "inbuff == "quit": above
                get_radio()        #<==  this will only execute if uart.any() is false...
                uart.write(">> ")  #<==  and, in that case, inbuff will be empty
    

    Just my thought on this...

    dgately

  • RsadeikaRsadeika Posts: 3,837

    Sorry, I was doing some multiple copy and paste to get it into the post, and something got corrupted.

    The one thing that I am really starting to dislike about Python is that indentation stuff. On a small program it is fairly easy to catch and fix, but on a larger more complex program, you will be pulling your hair out. Maybe a Raspberry Perl is something to think about.

    Ray

  • @Rsadeika said:
    The one thing that I am really starting to dislike about Python is that indentation stuff. On a small program it is fairly easy to catch and fix, but on a larger more complex program, you will be pulling your hair out. Maybe a Raspberry Perl is something to think about.

    What editor are you using? I've never had a problem with indentation in any of the editors I've used, but I wouldn't want to try writing Python (or anything else, for that matter) in e.g. Notepad.

  • RsadeikaRsadeika Posts: 3,837

    I was using Geany then I switched over to Thonny, I also tried MU for micropython. Because I work between Win 10 and Linux, I have ti find something that works in both systems.

    Ray

  • RsadeikaRsadeika Posts: 3,837

    I have a Raspberry 5 and I have connected a micro:bit. I am using Thonny with the latest interpreter update for micro:bit. I am having a couple of issues, maybe if somebody has an RPi 5, if you could run the program below and see what kind of issues it will have, if any.

    First issue, the quit function, not sure why it is taking such a long time for the command to respond.

    Second issue, I am using '@run_every(s=5)', this seems to be bogging down the program. Not sure what the next problem would be, if I expanded the program.

    This program, when run on my Win 10 machine, it does not have any of these issues. I get the feeling that Thonny runs just a little bit different on the different machines. This is making Thonny all most impossible to use, if you will be switching between different machines.

    Ray

    #test_it.py
    from microbit import *
    import sys
    
    uart.init(115200)
    
    display.clear()
    
    @run_every(s=5)
    def loc_temp():
        #global token1
        temp=(((1.8*temperature())+32)-1 )
        temp_string=str(temp) + 'F'
        token1=str(temp)
        display.scroll(temp_string)
        sleep(5000)
    
    def gen_temp():
       temp=(((1.8*temperature())+32)-1 )
       temp_string=str(temp)
       print(temp_string)
    
    
    print("Master Micro:Bit System")
    uart.write(">> ")
    
    while True:
        inbuff=""
        if uart.any():
            inbuff=uart.read().strip().decode()
            uart.write(">> ")
    
    # QUIT
            if inbuff == "quit":
                #f.close()
                print("Program has ended.")
                sys.exit()
    
            elif inbuff == "temp1":
                gen_temp()
                uart.write(">> ")
    
            else:
               uart.write("???") 
               uart.write("\n>> ") 
    
    
    sleep(100)
    
  • dgatelydgately Posts: 1,630

    I have a Raspberry 5 and I have connected a micro:bit. I am using Thonny with the latest interpreter update for micro:bit. I am having a couple of issues, maybe if somebody has an RPi 5, if you could run the program below and see what kind of issues it will have, if any.

    First issue, the quit function, not sure why it is taking such a long time for the command to respond.

    Second issue, I am using '@run_every(s=5)', this seems to be bogging down the program. Not sure what the next problem would be, if I expanded the program.

    Don't use @run_every(s=5) in this particular code... I ran the code without '@run_every(s=5)' on an RPi5, in Thonny with a Micro:Bit and it responded fairly well. It did on several attempts require some time for a 'quit' to complete. I also got some garbage characters after the code printed the temperature, but it would send the appropriate '>>' and I was able to continue sending 'temp1' and a final 'quit' to the Micro:Bit.

    Why use @run_every(s=5) ? You already have a 'while True:' loop. @run_every(s=5) will just restart the whole code every 5 seconds. And, that may interrupt the running loop. Short loops in micropython (I guess with any language, possibly) also have an issue with being interrupted by Thonny or Control-C or Control-F, as the loop (& constant run_every 5 second restarts) may be just giving too short of a period to allow serial input from an app or terminal. (In my very simple-minded view)...

    There can also be a problem when an existing 'main.py' (with a very short loop) has been saved to the Micro:Bit. It runs automatically on activating or restart and may become un-interruptable (see: https://forums.raspberrypi.com/viewtopic.php?t=321332 )...

    BTW: What makes your while loop so small??? Answer: Your sleep(100) is actually not inside the while loop & does not execute, ever!

    dgately

  • RsadeikaRsadeika Posts: 3,837

    Thanks, ggately.

    "Why use @run_every(s=5)". I wanted to have the temp shown via the display.scroll() constantly. In the 'while True:' loop, it only displays when the uart.read() is satisfied. I was trying to create a two task system. This is interesting, when you use Win 10 Thonny, this seems to run just fine. Not sure why the RPi 5 Thonny falters.

    Ray

  • dgatelydgately Posts: 1,630
    edited 2024-07-03 04:45

    @Rsadeika said:
    "Why use @run_every(s=5)". I wanted to have the temp shown via the display.scroll() constantly. In the 'while True:' loop, it only displays when the uart.read() is satisfied. I was trying to create a two task system. This is interesting, when you use Win 10 Thonny, this seems to run just fine. Not sure why the RPi 5 Thonny falters.

    Ah, remove the 'sleep(5000)' in loc_temp(). And, place the sleep(100) inside you while loop so it executes everytime through the loop. The loop needs some time to allow serial input to buffer (my guess). You may even need to make the loop sleep more than 100 milliseconds. Try 100, 200, 300 and see if that helps.

    Not sure why the RPi 5 Thonny falters.

    Different processor speeds, different OS... Also, I would expect there are differences in micropython on WIN and RPiOS.

    dgately

  • RsadeikaRsadeika Posts: 3,837

    I am replacing my RPi 5 with a Win 10 NUC to run Thonny and a micro:bit. If Thonny does not run correctly, then I might have to try MU on the NUC box. This project is starting to be more of a PIA than it is worth. Hopefully I will stumble over a solution that I think will be a satisfactory one.

    Still not giving up, yet.

    Ray

Sign In or Register to comment.