I need to send the data of two potentiometers across the 433mhz radiowaves. From what I have gathered I need to use the parse-tabular-mtw node on the receiver end and split the string. Im confused on how this node works. When I tried earlier I couldn’t get data from both potentiometers but only from 1 of them. How do I do this?
You need your transmitter to send a string containing the values from both potentiometers. Try the following (untested) patch:
You can use the format-number node to specify the number of decimal places for your potentiometer values. In the patch above the concat node creates a string containing your two potentiometer values, delimited by a comma.
On the receiver we can use the parse-tabular-mtw node to unpack the potentiometer values from the message string:
parse-tabular-mtw splits the string on a delimiter character, in this case a comma (hex: 2C). The IDX (index) input specifies which part of the split string we want to output (0 for the first, 1 for the second and so on).
Hope this helps. I haven’t had chance to test the patches, so apologies in advance for any errors!
2 Likes
Thanks! When I get home from work I’ll give this a shot and see if it works.
I just tried it and it worked. Thanks!
I do have another question now. I just got done testing out a 3d printed car with the remote control setup. It was really fun except for the stupid wheels kept coming off the car which I need to redesign better, but I noticed that when the vehicle lost signal with my remote that it just kept the last signal it had and lol it just kept going straight. At least I believe thats what was going on. Is there anyway to make the signal go to zero automatically when it loses connection?
I assume your current code changes what the car is doing every time it receives a code from the remote. If you push forward once, it will start moving forward until it receives a different code. If you want to have it stop when it loses signal, you will have to keep pushing forward to have it go forward and stop when it receives nothing.
One way to code this is to use a delay node to specify how often you need to give a new code to keep the robot moving. If the time expires, you stop the robot. One option for implementing that is a select node. Here is an outline using tweak-string to demonstrate the idea. The pulse node is pulse-on-change to reset delay time and select code as action. When delay expires, “stop” is selected. delay-T is how long the robot will continue after it is out of range (or just after the last button is pressed). Pressing stop will still stop the robot before delay expires.
I guess this will NOT reset the delay if you keep pushing the same button. The code above has a REC output pin on receiver. I assume this is to indicate something has been received and it can be used instead of the pulse-on-change node to reset delay and pulse select-S2.
Cool. Thanks that makes sense then for why its doing what it’s doing. Thanks for your help.
Well I set up a clock node on the transmitter arduino with a tick of .05 seconds and connected to a count node. The count node counts by 1 and its connected to an equal node that will send a true out when 1 = 1 and that is sent to the count node to reset it. So now I have a constant pulse of 0 and 1 that is then sent over the radio waves.
On the reciever side I take the 0 and 1 and hook it up to a pulse on change node. So now I have a constant pulse as long as the transmitter is connected. The pulse is used to set a delay node and when the delay node doesn’t get the pulse it does it thing and the robot stops.
Now the problem I have ran into now is that even though the clock tick is set to .05 seconds. I’m not getting that on the other side. If I was I should easily be able to set the delay node on the receiver side to a delay of .2 and the pulse on change will easily keep resetting the set pin on the delay node and keep it active. The minimum number I have found to work on the delay node is .7 seconds. This means the pulse from the transmitter is a little under .7 seconds.
I’m not sure if this is a lag set up in the transmitting of the radio wave or if this is a bug in the program? Or possibly both? I do see some lag in the readings coming from potentiometers from the transmitter and reaction from the receiver but it doesn’t seem to be as bad as .7 seconds of lag. There is definitely some noticeable lag though.
Also when I have the transmitter hooked up to the computer and I have it in debug mode and I’m looking how fast the 0 - 1 changes numbers. Its definitely not a blur of a change every .05 - .1 seconds or so. I was just thinking maybe that’s just how the program shows the changes? But maybe its not changing as fast as it should though?
Any opinions on whats going on? Or what I could do to drop the delay time reaction down to something lower.
Yeah there is a good amount of lag from the potentiometers as well. I don’t think the transmitter is sending packets fast enough. Is there any way to speed it up?
count.xodball (4.1 KB)
I created this program to test for lag and tested it alone and the count was 1,800 in 10 seconds.
Now I copied and pasted the same program into the program with the transmit code on it and this time I only was able to get 24 count in 10 seconds. So basically I kind of came to the conclusion that the lag is coming from the Program slowing down the processor on the Arduino too much or at least is too much for the processor to handle?
Very likely. Anything that is timing critical (like serial communication) is likely to use timing code that doesn’t release the CPU to process other threads since it would be very likely not to return CPU control in time to send or receive the next bit of data. Even if CPU is not pegged, it is not available for processing other code.
I tried again with the transmit program and all I did was remove the Transmit node from the program and this got me a count of around 450 in 10 seconds. So yeah I believe you are right. This is nice stuff to know.
WOW! Today I just discovered that the Receiver or the 433-rf-receive Node for Waylands 433mhz radio nodes, actually came with a REC pin. This pin sends out a pulse every time it receives a message. It was what I was trying to do, before I knew this pin even existed. I feel too autistic right now. I drove my car with pretty accurate results today, because I found out about this pin! I changed my code to work with it and it’s doing better than before. I still have bugs I need to work out ( like doubling the pwm signal to the side motors, the car has trouble turning and that’s my fault) but I’m glad I learned from this. I will say there is still some room for improvement but I can now use my delay node that shuts the system down after a signal lost at a minimum of .4 seconds now ( if I go lower than that the PWM signal from the potentiometer reading goes to 0 and back to the potentiometer reading every half a second or second or so and just switches back and forth )and before it was at .7 seconds. I wish I could get the delay node to a lower number, but .4 isn’t too bad.