Good news, I've almost got the XBee + WAV + ActivityBot 360 (receiver) working in BlocklyProp. It works now, but you have to enter your values twice to get it to change. Taking a break now, and will try to fix that later tonight. You don't need to change the transmit C code you have.
To be clear, I'm trying to get back around to something very similar to the code you started with. I don't have your board and I don't know your circuit, so I am working with what I have and can test on my own bench for now. That's why the application is using a terminal.
...Will the ActivityBot be able to accept commands from the XBEE and change movement (moving continuously) while the wav is playing?...
Sorry, I missed this. It can, but it depends on how it's written. If using a pause to allow the song to finish, it gets in the way of doing other things. A wav_playing function (WAV status block) was added that allows the main loop to check check the status of the wav file each time through. In most cases, this makes it possible to for the main loop to periodically check if the WAV file is playing instead of forcing a cog to pause for the duration of the audio.
One thing I would suggest trying in C is moving that line out of main and putting it as the first line of receiver(). I've written a few programs using a bluetooth receiver in its own cog and always did the fdserial_open in the bluetooth cog.
If it's using cog_run, it would be declaring the serial stack inside the serial monitoring stack, which seems like it might have a memory penalty. If it's using cogstart, the stack for each cog can be declared globally without having to make enough room for one cog's stack inside another.
I tried your last " test wav Play with ActivityBot Forward XBee and Custom TXRX(single value)" and it worked as I intended
when started the bot program.(sings while moving)
I am sorry I could not get back to you faster due to circumstances beyond my control.
Comments
Thank you very much, I am very early beginner for both c and blocklyProp.
I don't think I am upto it.
Keep doing the good work
Siri
http://learn.parallax.com/tutorials/series/activitybot-blocklyprop-tutorial-series
Especially what's in the Main Lesson(s).
Test Wav Play with ActivityBot Forward XBee and Custom TXRX
To be clear, I'm trying to get back around to something very similar to the code you started with. I don't have your board and I don't know your circuit, so I am working with what I have and can test on my own bench for now. That's why the application is using a terminal.
Test Wav Play with ActivityBot Forward XBee and Custom TXRX (single value)
I still used a terminal to test it, but I think I correctly emulated what your switch control is doing. Please try it and let me know if it works.
Sorry, I missed this. It can, but it depends on how it's written. If using a pause to allow the song to finish, it gets in the way of doing other things. A wav_playing function (WAV status block) was added that allows the main loop to check check the status of the wav file each time through. In most cases, this makes it possible to for the main loop to periodically check if the WAV file is playing instead of forcing a cog to pause for the duration of the audio.
If it's using cog_run, it would be declaring the serial stack inside the serial monitoring stack, which seems like it might have a memory penalty. If it's using cogstart, the stack for each cog can be declared globally without having to make enough room for one cog's stack inside another.
I tried your last " test wav Play with ActivityBot Forward XBee and Custom TXRX(single value)" and it worked as I intended
when started the bot program.(sings while moving)
I am sorry I could not get back to you faster due to circumstances beyond my control.
Thank you very much for solving my issue.
Siri