Hey there trusty SO community,
I'm working on a project for my new Samsung "The Frame" TV using a IR remote controller. I am trying to send a "repeating" command (when a button is held continuously). I have no problem sending single commands, I am able to control almost everything I need at this point.
Unfortunately, sending the "power" code on the Samsung Frame TV simply selects the "art" mode. Using the original RF remote, the power button has the same action: "art" mode vs TV mode. In order to turn off the TV with the original RF remote, one has to hold down the power button for a second or two.
So I assume that the IR remote interface would be the same.
I have tried sending all sorts of commands (left arrow, right arrow, volume+, etc...) in repeat mode, but the TV only ever responds to the first command and ignores the "repeat" signals. To be clear, the repeat code blocks are being sent, but for some reason ignored. I was able to validate the repeats are sent correctly using a separate sender and receiver.
I have a working prototype of a custom remote that uses this arduino library
I have also read through this SO thread which is incredibly helpful in understanding the protocol.
I wasn't able to find exact information on the protocol of a repeat command, perhaps there is a bug in the library?
line of code that works for single commands:
IrSender.sendSamsung(0x0707, 0x02, 0); //address, command=pwr, number of repeats = 0
line of code that sends the repeat code
IrSender.sendSamsung(0x0707, 0x02, 10); //address, command=pwr, number of repeats = 10
Thanks in advance,
It turns out that version 3.7.1 and earlier of Arduino-IRremote library implements a "special" repeat handling message. After comparing the repeat protocol to a Samsung Brand remote control, it was found that the repeat messages are actually identical to the single message.
An update was made to Arduino-IRremote in this ticket to fix the Samsung repeat messages.
A release has not yet been created as of typing this, but assume version 3.7.2 or greater will support Samsung correctly.
Related
I am a bit new here, English is not my native, so I am sorry for any possible misspelling.
I have a very odd problem - my Xiaomi Mi Surface Display 34" (XMMNTWQ34 model) monitor buttons act really strange - instead of calling the monitor OSD, pressing any of 4 present buttons tries to switch to another possible input source (this is even not their function!), but no luck: just 3 seconds of the black screen and it turns back to the initial image. Let me explain how I got into this.
I have a monitor named before, which has 4 input ports: 2 DP and 2 HDMI. There is a PC always connected to the monitor via the DP interface (DP1 to be exact). Today I tried to connect a second PC via HDMI to the HDMI1 port. It went totally good, I was able to switch between PCs using a monitor OSD. But I thought it was too long and complicated to press a dozen buttons on OSD just to change an input source, so started to google any other programmatical methods of doing such thing.
Some fact: there are no drivers for this monitor on the Internet (it actually works at full 3440x1440#144 Hz resolution/refresh rate via DP interface without any trouble, but Windows sees it as "Generic PnP Monitor", so I see no way to fix it without a relevant driver).
I have found that any VESA-compatible monitor has the 0x60 parameter, which means exactly "input source", so altering the value of this parameter switches the input source without the need to call an OSD. I have found that the possible values of this 0x60 parameter for my monitor provided by several utilities are: 0x0F, 0x10, 0x11, and 0x12. But setting any of these values got me no luck - the screen just flashed black and nothing more. Moreover, those utilities showed that the current value of the 0x60 parameter was 0x07 - described as "S-Video 1" input source, and it did not change at any made tries. But my monitor does not even have such input ports!
But I discovered a total disaster a bit later - when I tried to switch the input source via OSD, I was not able to call it - any of the 4 buttons on the monitor was causing a black flash and nothing more! So OSD is now totally unavailable! This is madness. I can't enter the OSD, I can't change the input source without turning off any one of 2 connected PCs, I can't do anything which is supposed to be made via OSD. Rebooting and reattaching of every possible thing has no effect - even with 2 PCs being connected to monitor and waiting to enter a BIOS password (no OS loaded whatsoever): pressing any button on the monitor causes only black flash and nothing more, no OSD called. I guess this is a strictly monitor firmware issue because the OSD worked well until yesterday.
I have absolutely no idea how to solve this, I googled this all day long, but no luck. System restore did not change anything. Please help. Thank you all very much.
Same issue after using ControlMyMonitor App. At the time being, i didn't found any solution to get the OSD back. And I didn't found any solution to factory reset the monitor, I don't know if it's possible.
I strongly discourage users to use any kind of VESA com application on this Xiaomi 34 monitor !
Now, the best solution in order to switch inputs, is to disconnect or shutdown one of the computer connected, ans it will switch automaticaly to the only one remaining. (Or use a VESA script...)
I am trying to make the Nano33SenseReceive example of the ChirpSDK 3.4.0 work on a newly bought Arduino Nano 33 BLE Sense.
I have added my credentials to the credentials.h file and uploaded the sketch to the board. I am playing the sounds from the vimeo videos embedded in this Arduino Project Hub page using my laptop speakers but nothing gets printed on the serial monitor and the LED does not turn on.
To test if the sketch starts, I added a line:
Serial.println("Serial started.");
just after the:
while (!Serial);
and it prints the line just fine, once I open the serial monitor, so it seems the sketch is running properly. This, however, is the only thing I get on the monitor, no matter how many times I play the sounds.
Any ideas what could be going wrong?
(Edited after responses by Dinu and joerobot)
I have managed to make it listen by using 16khz-mono-embedded. However, although the code now hears the sound, it fails to parse it. Here is example output from the monitor:
Chirp SDK initialised.
Receiving data...
Received data: ⸮
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data: ⸮
Receiving data...
Received data: ⸮
On the plus side, I had absolutely no idea a left-to-right flipped question mark existed so can't complain much. On the minus side it's a bit disappointing to see that the mic can't figure out a chirp at a few centimeters from the speaker in a quiet room. Having said that, it's still early days so I 'm hoping future version of the SDK will iron out performance issues.
(Edited to add hardware details)
I have tried two laptops, one Clevo with Onkyo speakers and an Intel sound card and one Lenovo X1.
I have also tried my phone, Lenovo K33a48.
In all cases, I uploaded a fresh copy of the example file in File > Examples > ChirpSDK > Nano33SenseReceive and played the vimeo videos embedded in this page at full volume, right next to the Arduino. Here is a direct vimeo link to one of the videos.
Every time, I get theReceiving data... message, showing that the transmission is understood as such but then I get the empty Received data:, occasionally with the left to right question mark.
The config string from the credentials.h correspond to a specific protocol. Make sure your app on the developer's website is set with the correct protocol , which is 16khz mono in the video if I'm not wrong.
As Joe mentioned, 16khz-mono-embedded needs to be used for Arduino
I had this issue too - turns out the problem isn't in the receiver at all, but in the data being sent.
For whatever reason, the videos that you linked that should be sending RGB values just seem to give the backwards ?.
If you use messenger.chirp.io to generate sounds then the message will be displayed correctly in the serial monitor.
I am broadcasting Hello using one Xbee (say A).....Xbee (say B) and Xbee (say C) are receiving a lot of garbage values before and after Hello.
All the baudrates are 9600...where am I going wrong?
It would help if you posted an example of the data you see, perhaps the hex values of each byte.
My guess is that you've configured the modules for "API mode" which wraps payloads with a header (starting with 0x7E, the character ~) and footer. It's useful for "smart" devices because it supports multiple packet types.
Check your settings, and make sure you're using ATAP=0. You can use XCTU to change the settings, or from a terminal use the escape sequence (1 second pause, +++, 1 second pause then module should respond with OK) to enter command mode. In command mode, first set ATAP0 and then ATWR to save the changes.
I'm quite new to working with Arduino/GSM and have had problems getting basic HTTP functionality working. I am currently facing multiple problems - one being that the 3G shield I am working with (SIMCOM SIM5216A) does not seem to want to connect to a carrier! :(
However, the problem I would like to focus on for this question is that Phone Functionality - designated through the AT+CFUN command - does not seem to be maintained through power cycles. Additionally, sometimes after modifying the CFUN, the modem will run a soft reset.
Here is the command I have been using to modify the phone functionality of the modem:
AT+CFUN=1,0
I am under the impression that the second parameter should stop it from running a soft reset.
I have attempted to save the AT configuration by following advice in this question's accepted answer - here is the output from power on:
START
+STIN: 25
+STIN: 25
+CPIN: READY
SMS DONE
PB DONE
AT+CFUN=1,0
OK
AT&W
OK
However, whenever I next reset, I will get the following:
AT+CFUN?
+CFUN: 4
OK
So, my question is how can I save the CFUN configuration to be consistent between power cycles? (If you happen to be able to offer advice on why I can see medium-strength signal but cannot connect to an operator network, any advice would be welcome there too, however that is not the focus of this question)
With thanks,
BadDevH.
Exactly what that is saved with AT&W is a rather muddled, see this answer for details. However, regardless of that, the AT+CFUN command is controlling such a dynamic behaviour that I cannot imagine any manufacturer ever that has saved this with &W. Think more of CFUN more like setting a fixed cruise control speed while driving a car. There is no way the car will continue with the speed from last time when started.
For normal phones the default behaviour is value 1 - full functionality - because that is the very core functionality of what they do1, but for a GSM module shield, I am guessing that the default behaviour is set to no radio in order to save power, so it stays off until you need it at which point you need to explicitly turn it on.
1
And even in the case of no sim card present, it shall still be able to make emergency calls.
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)