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.
Related
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.
I'm developing a web front end for a GNU Radio application developed by a colleague.
I have a TCP client connecting to the output of two TCP Sink blocks, and the data encoding is not as I expect it to be.
One TCP Sink is sending complex data and the other is sending float data.
I'm decoding the data at the client by reading each 4-byte chunk as a float32 value. The server and the client are both little-endian systems, but I also tried byte swapping (with the GNU Radio Endian Swap block and also manually at the client), and the data is still not right. Actually it's much worse then, confirming there is no byte order mismatch.
When I execute the flow graph in GNU Radio Companion with appropriate GUI elements, the plots look correct. The data values are shown as expected to between 0 and 10.
However the values decoded at the client are generally around 0.00xxxxx, and the plot looks like noise rather than showing a simple tone as is seen in GNU Radio. If I manually scale the data by multiplying by 1000 it still looks like noise.
I'll describe the pre-D path in GNU Radio since it's shorter, but I see the same problem on the post-D path, where a WBFM Receive and a Rational Resampler are added, followed by a Throttle block and then a TCP Sink block sending float data.
File Source (Output Type: complex, vector length: 1) =>
Throttle (vector length: 1) =>
Low Pass Filter (FIR Type: Complex->Complex (Decimating)) =>
Throttle (vector length: 1) =>
TCP Sink (input type: complex, vector length: 1).
This seems to be the correct way to specify the stream parameters (and indeed Companion shows errors if I make changes which mismatch the stream items), but I can find no way to decode the data correctly on the other end of the stream.
"the historic RFC 1700 (also known as Internet standard STD 2) has defined the network order for protocols in the Internet protocol suite to be big-endian , hence the use of the term 'network byte order' for big-endian byte order."
see https://en.wikipedia.org/wiki/Endianness
having mentioned the network order for protocols being big-endian, this actually says nothing about the byte order of network payload itself.
also note: Sun Microsystems made big-endian native byte order computers (upon which much Internet protocol development was done).
i am surprised the previous answer has gone this long without a lesson on network byte order versus native byte order.
GNURadio appears to assume native byte order from a UDP Source block.
Examining the datatype color codes in Help->Types of GNURadio Companion, the orange colored 'float' connections are float32.
To verify a computer's native byte order, in Python, do:
from sys import byteorder
byteorder
the result will be 'little' or 'big'
It might be possible that no matter what type floats you are sending, when bytes get on network they get ordered in little endian. I had similar problem with udp connection, and I solved it by parsing floats as little endian on client side.
I'm trying to use a customized filter to receive video and audio data from a RTSP stream, and deliver samples downstream the graph.
It seems like that this filter was modified from the SDK source.cpp sample (CSource), and implemented two output pins for audio and video.
When the filter is directly connected to an avi mux filter with INTERLEAVE_NONE mode, it works fine.
However, when the interleave mode of avi mux is set to INTERLEAVE_CAPTURE,
the video output pin will hang on the GetDeliveryBuffer method (in DoBufferProcessingLoop) of this filter after several samples have sent,
while the audio output pin still works well.
Moreover, when I inserted an infinite pin tee filter into one of the paths between the avi mux and this source filter,
the graph arbitrarily turned into stop state after some samples had been sent (one to three samples or the kind).
And when I put a filter that is just an empty trans-in-place filter which does nothing after the infinite tee,
the graph went back to the first case: never turns to stop state, but hang on the GetDeliveryBuffer.
(Here is an image that shows the connections I've mentioned like)
So here are my questions:
1: What could be the reasons that the video output pin hanged on the GetDeliveryBuffer ?
In my guess it looks like the avi mux caught these sample buffers and did not release them until they are enough for interleaving,
but even when I set the amount of video buffers to 30 in DecideBufferSize it will still hang. If the reason is indeed like that, so how do I decide the buffer size of the pin for a downstream avi muxer ?
Likely a creation of more than 50 buffers of a video pin is not guaranteed to work because the memory size cannot be promised. :(
2: Why does the graph goes to stop state when the infinite pin tee is inserted ? And why could a no-operation filter overcomes it ?
Any answer or suggestion is appreciated. Or hope someone just give me some directions. Thanks.
Blocked GetDeliveryBuffer means the allocator, you are requesting a buffer from, does not [yet] have anything for you. All media samples are outstanding and are not yet returned back to the allocator.
An obvious work around is to request more buffers at pin connection and memory allocator negotiation stage. This however just postpones the issue, which can very much similarly appear later for the same reason.
A typical issue with a topology in question is related to threading. Multiplexer filter which has two inputs will have to match input streams to produce a joint file. Quite so often on runtime it will be holding media samples on one leg while expecting more media samples to come on the other leg on another thread. It is assumes that upstream branches providing media samples are running independently so that a lock on one leg is not locking the other. This is why multiplexer can freely both block IMemInputPin::Receive methods and/old hold media samples inside. In the topology above it is not clear how exactly source filter is doing threading. The fact that it has two pins make me assume it might have threading issues and it is not taking into account that there might be a lock downstream on multiplexer.
Supposedly source filter is yours and you have source code for it. You are interested in making sure audio pin is sending media samples on a separate thread, such as through asynchronous queue.
I'm currently developing a small application for monitoring the power / current our solar collector is generating.
The array is connected to 3 inverters. Every inverter has a RS232 interface, transmitting one Line of information(its current status) every 10 seconds.
Since I want to do the monitoring using a device only having one serial port, I need to come up with a way to be able to read the data from all of the inverters in parallel.
I don't need to send anything to one of the inverters!
Is it possible to just connect 3 RS232 wires in parallel to one serial port? Collisions will be pretty unlikely since every inverter is transmitting only 64Byte / 10seconds ending with a newline, so I could check for variable line lengths to detect collisions.
I'm sort of chuckling at doomsday and wacky answers that so often pop up on stackoverflow...
But anyway, in years gone buy I have used paralleled RS-232 transmit lines using diodes and it can work fine for situations where collisions are unlikely. In one particular application I used this technique there were two input terminals where a user could key in simple commands to control the system (a specialized security system) and it was very unlikely that two people would be trying to control it at the same time from the two different terminals. Amazingly enough there are no problems with voltage levels with most RS-232A receivers I tested at the time and they tolerated the signal characteristics (no negative voltage) that result from the simple use of the diodes in series with the TXD signals. However, if I had to do this again I would likely add a simple pull-down resister and capacitor to ground with a diode between RXD and the cap in a sort of charge pump configuration or a pull-down to negative going handshake signal to ensure the "OR'd" input signal goes truly negative since the RS-232 spec defines +3 to -3v as invalid.
In any case, I would recommend not using this technique except in very specific, limited, and non-mission critical cases and would not use it in the case where you have multiple devices sending information at a programmed interval as in the case of the OP or where there is a software handshake.
In can be a simple solution to the problem of not enough serial input ports but only in a very limited set of environments.
No, you should NOT connect 3 serial output port in parallel. If you do that you are probably going to broke the RS232 output circuitry of your inverters.
You have 3 RS232 outputs, so you need 3 RS232 input, then you can manage these 3 input the way you like: maybe you can buffer the data from each input, and reoutput the data on a single RS232 output, to be connected to your monitoring device.... but you should add some code in the data flow to differentiate the data coming from the 3 inverters.
Maybe you can use some kind of IC that do the job for you, I'm not sure, but maybe that some IC that multiplex multiple RS232 input on a single RS232 output already exist.
Try this search: rs232 port input multiplexer on Google
Or, if the monitoring device is a Window computer, you can use 3 serial-to-usb converter: that will create 3 virtual COM port on your computer and you can read data from them with any software.
Update
About the hypothesis of securing the output circuitry using diods to block reentering current, I don't think it's going to work...
Many year have passed by since last time I've used an RS232 link at low level (so maybe I'm wrong) but I think that there is some kind of handshake going on between RS232 input and output port (speed to use, parity, stop bit...).
Each RS232 port have inputs and outputs signal, both for data and for transmission control, so your multiple RS232 outputs does have some input signals, and your single RS232 input does have some outputs.
This mean that your input monitoring RS323 port is going to try to make a handshake with 3 RS323 ports at the same time... and the 3 RS232 ports are probably going to respond at the same time... so I think it's not going to work.
Other than that if you place diodes on your output, you are going to loose 0.7v, I don't remember the tolerance on signal level of RS232, but maybe that 0.7v can be relevant.
I would like to know how to capture packets of a specific wireless network using wireshark.
I'm already able to capture all packets of different networks setting my wireless card in monitor mode but for a specific analysis i need to discard all the packets not related to my network during the capture procedure.
I know that exists display filters to do that but i need to filter them ahead (like with capture filters).
If i go to CAPTURE->OPTIONS i can set capture filters but i don't know the exact filter because they are different from display filter infact wlan.bssid==xx:xx:xx:xx:xx:xx
does not work.
any suggestions?
thanks
You could use an index from the start of the wlan packet.
It needs some coaxing, but the BSSID field is in a fixed, predictable position. By using brackets, you should be able to reference the proper positions in the packet.
The BSSID is at position 16, so if you wanted to emulate something like:
wlan.bssid=12:34:56:78:9a:bc
you would have to do something like this:
wlan[16:4] == 0x12345678 and wlan[20:2] == 0x9abc
You have to convert the first 4 octets into a int32 and the last 2 into an int16 and use 2 clauses, as BPF cannot express a 6 byte number, but I've used it and it works fine. This can also be adapted to other uses as well (you just need the offset).
Excellent question and something I've been trying to figure out also.
The short answer is the wireshark tools cannot filter on BSSID. Wireshark uses pcap, which uses the kernel Linux Socker Filter (based on BPF) via the SO_ATTACH_FILTER ioctl. There is no BPF filter for BSSID.
Another tool, airodump-ng, CAN capture by BSSID because it passes all 802.11 frames into user space and decodes/filters frames there. It works surprisingly well considering all the user-space processing.
But even a low-volume 80211 network is fairly noisy. For example, my SOHO captures 11K frames in under two minutes; and I still drop frames. Grabbing all the 80211 frames for the five visible (but small!) BSSIDs near me and I receive 141K frames (104MB) in just under three minutes.
I'm looking to do an embedded frame sniffer/injector using EMMC or SD flash so I need to be careful about pushing the limits.
So I'm trying to write a custom BDF filter to filter only the local BSSID frames. And I hope to extend it to drop a good amount of the "noisy" frames - most of the control and management frames can be filtered.
The BSSID address location in the frame is based on ToDS and FromDS control bits.
Anyway, hope I provided some breadcrumbs to the solution. It may just be an airodump user-space solution is the easiest.