Volume vs Channel Remote Buttons: Difference?
lardom
Posts: 1,659
A remote control volume button increments but a channel button doesn't repeat. What's the difference?
My goal is to accelerate/decelerate, turn/straighten a 3 wheeled robot by pressing and holding channel buttons on a remote.
I'm experimenting with an object written by Bob Belleville. I'm testing my logic by controlling two LED's. The problem is I have to press a button repeatedly for changes to take place. What am I missing?
My goal is to accelerate/decelerate, turn/straighten a 3 wheeled robot by pressing and holding channel buttons on a remote.
I'm experimenting with an object written by Bob Belleville. I'm testing my logic by controlling two LED's. The problem is I have to press a button repeatedly for changes to take place. What am I missing?
Comments
The microcontroller in the remote probably treats the two type of buttons differently.
I had a heck of a time when I added support for SparkFun's Nordic fob to my Mood Enhancing LEDs project. It was easy to know when the buttons hardwired to the project were being continually pressed but the Nordic fob only send a single transmission even if the button was held down. I suspect the channel buttons also one sends a short burst from your remote.
http://www.electronics-base.com/index.php/general-description/ir-remote-control/137-sony-sirc-protocol
The numeric channel buttons are one-shot that sends the channel code 0-9
The volume control buttons send a repeated code that either increases or decreases the vol.
Another button reverts to the transmit a one shot of a previous channel by using a bit of memory.
Another button chances a completely different data bit field so that a VCR or other alternative device, rather than the TV receives the data from the channel buttons.
In is not a simple device.
I just purchased a much simpler IR remote that has only 0-9 buttons and a set of 5 direction buttons.
I am pretty sure the 0-9 is all one-shot transmission, but the direction buttons may autorepeat their code.
This kind of device is what I have always really wanted for projects, but the darn thing doesn't declare which IR code it actually uses. I have to dig through downloads of sample programs and an Arduino library to figure that out. Ugh.
I know that many remotes shut down if you hold a key too long, like 10 or 20 seconds. Thus ended my instant el cheapo IR beacon for navigation experiment.
RecordAndDisplayPwm.bs2
[/FONT][/FONT]
http://www.parallax.com/sites/default/files/downloads/70016-Web-IR-Remote-for-the-Boe-Bot-v1.1.pdf
Starts on page 33.
So, it depends on the remote AND the receiver. For robotics, if you can determine the the receiver continues picking up a stream of codes when a button is depressed, you can write your code to repeat the last valid command for as long as the stream of 0000000 codes are there.
You can always make your own remote control. Most controllers can generate SIRC and other standard codes. Parallax sells some nice (and cheap) joysticks. Use one of those to make any kind of remote you want, doing anything you want. I think Andy has a project like this on the Learn site (learn.parallax.com).
My favorites are Wii Nunchucks and PlayStation 2 controllers.
Of course this adds a whole new level of complexity to the project.
The 12 bit Sony code is by far the most popular example on the internet. This is the only one that Parallax seems to provide example code for.
http://www.hifi-remote.com/sony/
I believe it has 7 bits to designate the button down and 5 bits to address the device that should be listening. IN the Parallax BasicStamp examples, reception of only the first 7 bits is down, there is no verification of the device target. That makes the code simpler and shorter to process.
Other device have more bits, some have many more bits in each serial burst. And as I mentioned about, the array of features makes a big portion of the buttons useless for most simpler projects. It is easier to buy a simple, bare-bones remote.
This is the one I like and am attempting to verify if it is indeed Sony 12bit code
http://www.aliexpress.com/item/Hot-Selling-New-Infrared-IR-Wireless-Remote-Control-Module-Kits-For-Arduino-Wholesale/1373993649.html
IF you don't know the code of your remote. IN Linux, LIRC project has the software and schematics of the hardware to decode anything. But it is a big diversion from just getting a remote with a known code. AND, LIRC has a data base of known remotes and their button codes.
http://www.lirc.org/
There are ways for the object code to ignore the repeated transmissions of the IR Remote... effectively making repeat sends into a one-shot device. That might be what you are having trouble sorting out.
On the other hand, an LED might take a lot of input to show a noticeable change if the increments of increase and decrease are too small.
I will take a look at IR Kit.zip and see if I can get it working with my KEYES IR Remote which seems to not be anything like a Sony 12bit.
At least you seem to have the Propeller receiving and responding to the IR Remote control.
I am not sure how many actual bits the KEYES remote is, the Arduino code supposedly works with the Arduino lR library and manages to hide the generic info. Arrgh.
The zip shows where I was at the time I posted. I tried to replace 'press and hold' with toggle 'start and stop' but that did not work either.
I need a clearer understanding of the SIRC protocol and I have to write small code chunks to answer really basic questions.
It is correct to presume by the upbeat tone of your message that the problem is now solved?
I am just getting into using my new KEYES IR remote with the Propeller. So I don't know what I will run into.
A. I have used universal remotes in the past with the BS2 code. In that situation, the volume+/- and channel+/- buttons are auto-repeat.
B. I recently purchased a KEYES remote just because it doesn't have the clutter of all the extra buttons. I was hoping that it was a Sony remote and that I could get it up and running without too much fuss, but the device is supported by the Arduino world .. and they seem to go about things differently.
C. I downloaded the Arduino code in hopes of locating the format for the remote. No luck, but a list is provided of what the Raw Codes for each key are. The procedure to determine the remote is similar to IO_kit.zip. It doesn't identify particular remotes, but instead identifies the timing of the serial by various brands.
D. In the process of reading the Arduino code, I see that at the end of the listing a Delay(500) is inserted with a note that this blocks the Repeat function of individual keys. So that is possibly why you are not getting auto-repeat if available in the Propeller code --- a similar repeat blocking might be included and need to be removed
E. You could verify the auto-repeat by reverting to using a BasicStamp with their IR remote examples if the device supports a Sony 12 bit code.
F. Having confirmed the remote is working like you desire, it is obviously that the next step would be to go into the IR_kit object and figure out how to remove the code that converts to a one-shot filter.
++++++++++++++
The problems here are...
A. I am not sure what you are using for a remote and which code format you are working with. (I do need to open your .zip to see if that will tell me.
B. I may be working with an entirely different remote format and different remote control.
So there is a gap that can muddle up any help that I try to prove... different remote control devices, different programing languages.
I am attaching the KEYES remote code that filters out the auto-repeat. That might give you a clue how blocking auto-repeat can be done.
It is in C/C++ Arduino. And it depends on an IR library in Arduino. This is a cheap and available simple remote that would be wonderful to use with the Propeller, so I am trying to sort out what code it requires.
KEYES IR Remote code.txt
1. You appear to be using Sony timing.
2. The code includes a feature called 'repeatDelay'. That is likely what is blocking your auto-repeat. You may have to reduce it to zero or a very small number.
3. There is another feature in the Spin code that appears to modify the repeated code. This may be handy with a zero 'repeatDelay' as some auto-repeat buttons can be used as one-shot by only recognizing the first trigger, and others can recognize both the first instance and the ones that are modified. .. you just have to write the code to do so.
If you know how many bits your remote actually is, you might shorten that reading loop to fit the exact bit count.. so it doesn't miss the next repeat.
I found with the BasicStamp method, the repeats were actually a lot of trouble with triggering activity when one didn't want it. So I get that is why delay methods were developed.
In theory, they should be able to be removed. You might look at some other IR remote objects in OBEX.
I am having trouble with compiles if the IR_Kit.zip in Brad's Spin Tool and SimpleIDE. I am not exactly sure where the problem is. But I need to get something working to be of any further help to you.
Every manufacturer created a different scheme so their remotes would not work with other brands.. that is the why. It gets to be a rather big database of remote codes. But it seems that there are really only a few patents on the actual timing and roughly four, five, or six ones that are most popular and can be easy to identify.
Take a look at the IR_Kit.zip in OBEX and read the documents in it. The Arduino library takes a similar approach to identifying the IR remote codes. And I suspect this is how the Universal Remotes that are able to learn from your TV search for the right solution. Once the timing pattern is recognized (usually by a start timing sequence), the software actually listens for the longest possible bit patterns as the decoder just fills in the shorter bit codes with FF code or 00 code. It is pretty simple.
IR_KIT.zip has been very helpful. My KEYES remote is an NEC 32bit device.
Historically I suspect that the BasicStamp and PIC users preferred the Sony 12bit code because the actual button codes were 7 bits which fit nicely inside a byte. Of course, 32bit codes are no problem for the Propeller.
If you use IR_KIT.zip, you really cannot avoid reading and re-reading the README.pdf several times. It has all the answers, but a lot of useful background info as well. It lives up to its name by being a good kit of tools.. all the files are useful in different situations. You certainly do not have to use the Propeller TV video to use it, but it is an option. I just used the serial port options.
I really like the simple keyboard layout of this, the cheap price, and the IR sensor works fine with 3.3v Propeller power... so you don't have to provide 5.0v and then worry about the logic pin needing a resistor to protect the Propeller i/o. And there is a nice little 'goodie' on the IR Sensor.. an LED that blinks with serial IR is being recieved, so you know your sensor is working.
There must be a few beginners who would find the code useful. I'll post it when I'm done if there's any interest.
FYI, Philips' RC-5 protocol auto-repeat works differently. From http://www.sbprojects.com/knowledge/ir/rc5.php:
As long as a key remains down the message will be repeated every 114ms. The toggle bit will retain the same logical level during all of these repeated messages. It is up to the receiver software to interpret this auto repeat feature.
Thanks for the link you provided. It was the best explanation I'd seen to date. I followed your advice to look at the pulse stream in my USB scope. That made things a lot clearer. It made sense because I could see what was going on.
Oh, so he's the Sit-n-Sleep guy now? "You're killing me Laaaary!"
(Erco and any other SoCal folks here gets the joke. You can't spit without hearing a Sit-n-Sleep "....Or your mattress is freeeeeee!" commercial on the radio.)
Anyway, Larry, would you consider posting your solution to Obex, or if it's short, here? I'm sure others would be interested. Otherwise Laary might beat you to it.
I heard the 1KHz PWM motor noise. I have an object that runs PWM @ 20KHz in Spin but I think I read that the L293D tops out at 5KHz. (Test and repeat.)
These are the button assignments:
If you are using an L293 or L298, the technology is BJT and they have an internal voltage drop that can be as high as 2.0 volts. So powering from 5 volts is barely going to deliver 3 volts. If this is your problem, you could boost the 5volts to 7 volts with a boost regulator and the motors would then get 5 volt drive. It might work, or it might burn up the motor's brushes.
Polou has a wide selection of motors with related wheels and motor mounts. They also have MOSfet H-bridges which have a much lower voltage drop. All good stuff to get the most power from the battery to the motor.
I'll order a pair of geared motors from Polulu and re-test. Thanks for the advice.
Though they work, they run so hot and waste so much power that people should be shouting "obsolete".
Geared-motors really allow the motors to run at higher RPM and that means that they provide more torque. Direct drive is certainly part of your problem, but not all of it.
Expecting to use BJT h-bridges makes the problem worse.
Expecting to run DC motors at low voltages heaps on more trouble.
If you have a 7.2VDC battery pack or lower, use a boost regulator to drive your motors at 12, 18, or 24 vdc. The vast majority of DC motors will have a maximum voltage of something like 36 or 48 volts.
You will have less losses from inside your h-bridge (a 2 volt drop in the h-bridge at 24 volts is a much smaller percentage that 2 volts at 5 volts).
And the higher the voltage, the less losses you have from small diameter wire.
My review of the motor/wheel combo I tried never showed up on the MPJA website. I'm still a bit miffed at the sites claiming these would be great for a small robot.
What sort of motor/wheel combo were you using Larry? Never mind. I see you purchased the motor at Radio Shack. It can be hard to find a good application for a motor without a gearbox.