I'm building a small robot that uses a relay to power the motors. To run the relay, I have it connected to pins 11 and 12. If I use something like the Blink example, where it turns the pin on, then off a second later, it works fine. However, what I'm trying to do is keep a pin on until an IF statement is met. When I run it, it turns the pin on for a millisecond or so, then off permanently. How could I get this to work?
Well, I have a couple guesses, but your description is vague without knowing what the IF statement is...maybe it is being met somehow without your knowledge.
I am pretty certain the light is staying on longer than a millisecond in order for you to see it. As a side note, here is an interesting, related article: http://www.100fps.com/how_many_frames_can_humans_see.htm
Are you debouncing? http://arduino.cc/en/Tutorial/Debounce
I can imagine a simple program with an IF to count button presses -- or the timing of -- where, without debouncing, you will meet the conditional without it seeming correct.
This is just one possibility, but without knowing the code, or the setup it's hard to say.
I have captured the IR signal ( I believe RC5) of a HVAC remote control, like this one....
(using Saleae)
This gave me a sequence of pulses of different width that I can make the Arduino reproduce and the HVAC recognize the request. An example is:
unsigned int power_ON[180] = {2888,3918,1911,1049,907,1992,903,989,1936,1023,907,1049,903,989,903,1049,903,1049,907,1992,1851,1992,1915,1049,928,963,928,1023,903,1049,907,1049,928,963,928,1023,903,1053,928,1023,928,963,928,1023,928,1027,928,1023,928,963,928,1023,907,1049,928,1023,928,1906,1941,959,2940,3866,1962,997,932,1967,929,963,1962,997,933,1019,959,933,933,1023,954,997,928,1971,1902,1941,1941,1019,958,933,958,997,954,997,933,1019,959,933,959,997,954,997,928,1023,958,933,958,997,954,997,933,1019,958,933,958,997,954,997,933,1019,958,1881,1962,937,2940,3862,1966,993,958,1941,933,959,1966,993,958,997,954,937,954,997,933,1023,954,1941,1880,1966,1962,997,954,937,928,1023,933,1023,954,997,928,963,928,1023,933,1023,929,1023,928,963,929,1023,928,1027,928,1023,928,963,928,1023,928,1027,928,1023,928,1910,1911,989,3832};
Could anyone guide me on the steps to decode the message? or understand the different pulse width?
I guess there must be certain defined pulse widths? Each meaning something different?
My initial though is that I need to:
1) Decode raw data by converting pulses to digital 1,0
2) Identify from digital data each section of the code, I think all the configuration is send on every key press, so identify the section of the code where it states the temperature, fan speed, hvac mode, clock, etc
3) Be able to put together a full IR code based on wanted setup, instead of just saving the whole code and reproducing it.
Any hint or guideline on how to do this?
Am I on the right track?
edit:
I have tried analysing one same mode and try to figure out which pulses change, but I cant figure it out as the number of pulses varies. Here you can see Cooling mode and maximum fan speed with changing temperature setting.
here is the excel file for anyone really into helping:
http://www.filedropper.com/analysiscoolingmodefanspeedmaximum
and the end of the message
So I put your pulse widths (?) into a diagram: http://i.imgur.com/C9k64qB.jpg
Without knowing more about what this actually represents, this does not really help i guess..
What buttons did you press while recording this? How did you record this?
I would try to visualize all the data you can get. Record all buttons and put what you get in diagrams. Then stare at them and maybe you will find some logic hidden in there.
Also, open the remote, look what IC's are inside and look up their datasheets. Maybe there you will find the protocol and you won't have to do any reverse engineering at all.
Keep us updated!
Im working on a program to send and recieve SMS using a GSM modem and my computer.
I have gotten sending and receiving to work - well sort of.
Once in a while my program is sent into a total chrash due to modem is mixing up information about Radio Signal Strength Indication and alike, while also serving my program with the hex code for the message.
My code can handle the hex code just fine. but I have seen the following line popup while im decoding a byte stream:
^RSSI: 2
So far I've seen it send out values between 1 and 10.
Is there an AT Command that can disable them? I have no need for them.
Or alternative: Is there a general syntax for them, so I can filter them out before decoding?
Im leaning towards a filter solution. But that would be more easy to implement if I knew whenever modem is sending out on the form: "^SOMETHING: xxx", then It would be nice to know if it is always followed up be a delimiter say for instance "\r".
You should try turning off periodic messages as using AT^CURC=0.
Information regarding the AT^CURC command:
AT^CURC? Current setting of periodic status messages
AT^CURC=? See what you possible values are
AT^CURC=0 turn off periodic status messages
The best way to tackle this scenario would be to replace that part of the response with an empty string because otherwise, it will be difficult to check even if the command sent to disable it is working or not.
This regex will match all those. You can replace them ideally by an empty string.
(\\n|\\r|\\r\\n)\\^.*(\\n|\\r|\\r\\n)
I have a DirectShow webcam application. I make use of Sample Grabber to get the buffer callbacks and IVideoWindow to control the display co-ordinates for the Preview. I have Preview and Capture Streams which I run as below.
g_pBuild->RenderStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video,cam,g_pGrabberF,pNullRenderer2); g_pBuild->RenderStream(&PIN_CATEGORY_PREVIEW, &MEDIATYPE_Video,cam,NULL,NULL);
On certain On board cameras, IMediaControl::Run followed by IMediaControl::Stop followed by IMediaCOntrol::Run doesn't switch on the camera.
Extenal USB cameras work properly here. How can I diagnose more on this? Any pointers, please help.
Maybe its specific to a certain hardware issue in the unit.
Do a quick test by adding sleep of 1 sec between calls.
If it does help than you need to find a way to know when to unit state in idle or not.
There are two important parts of the question which you did not provide:
Filter graph topologies
HRESULTs of the method calls
A problem you might be having is that one of the filters in the topology does not handle well state transitions and fails somewhere between states. Supposedly your second Run meets it still trying to complete Stop. You might get a HRESULT there which indicates the issue (better for you) or the filter fails silently.
The filter graph's is the unlikely source of the bug itself. Chances are high that it does everything flawlessly, however since internally it distributes the calls between filters, one of the filter is letting you down.