I am trying to build an RFID based door opener with an Attiny2313 and an RDM630 RFID reader. There has been no Problem with programming or getting the two ICs to talk to each other via UART. The Problem is the interpretation of the data.
I wasn't able to make any sense of what the RDM630 had sent to the Attiny, so I hooked it up via an RS232/USB Adapter, and this is what I get on my PC:
Display = ASCII:
Display set to HEX:
Written on the Card is:
0000714511 010,59151
Can anyone help me make sense of the Data?
Most of the bytes that the RDM630 RFID reader module sends are ASCII characters of hex digits ('0'-'9','A'-'F') which means 0x30-0x39, 0x41-0x46.
It looks like your RS232/USB inverts the bits, comparing to a direct TTL connections.
(RS232 is inverted TTL. It has also different voltage levels, but that's OK as long as TTL transmit output feeds RS232 receive input, as in your case. The other way around is more tricky).
Related
As far as I unterstand BLE uses two 1-bit fields for applying sequence numbers to packets (SN, NESN). From my (admittedly basic) knowledge about (wireless) communication a 1-bit sequence number is perfectly fine as long as a sender does not continue sending data until the last message is acknowledged by the receiver.
Because of that it is trivial to understand how BLE works with a one-packet-per-interval scheme. However BLE allows multiple packets in a single connection interval. So far I couldn't find any information on how this scenario is handled without allocating more bits for larger sequence numbers.
Any pointers in the right direction on where I'm going wrong or where I can read up on this would be appreciated.
I have the following problem. I am using WS2811 diodes, Arduino Due and node.js to my project. I want to stream video from a device connected to a node.js server and show it on array of diodes. Right now I am able to capture video from any device with browser and camera, change resolution of the video to this desired by me (15x10) and create String chain containing informations of all colors (R,G,B) of all diodes. I am sending it from node.js server to arduino though serial port with baud rate 115200. Unfortunately sending process it is too slow. I would like it to refresh the LED array at least 10 times per second. So I was wondering maybe to compress this string which I am sending to arduino, when it gets there decompress it, and set colors to diodes. Maybe you guys have some experience with similar project and advice me what to do.
For handling diodes I am using adafruit_neopixel library.
If I were you I would try to convert the video to a 16-bit encoding (like RGB565), or maybe even 8-bit, on your server.
Even at that low resolution I'm not certain the atmega328p is powerful enough to convert it back to 24-bit and send the data out to the display, but TIAS. If it doesn't work, you might want to consider switching to a BeagleBone or RPi.
If you have large areas of a similar colour, especially if you have dropped your bit depth to 16 or 8 bits as suggested in the previous answer, Run Length Encoding compression might be worth a try.
It's easy to implement it in a few lines of code:
https://en.wikipedia.org/wiki/Run-length_encoding
I'm able to pair and send data no problem, but i've come across an issue where the receiver will receive and interpret the data byte by byte instead of a string of bytes. This is a problem because we are the data sent are values read from a potentiometer. If the potentiometer changes too fast, the receiver isnt able to read the changes fast enough. Any suggestions on how to do this?
My current setup is an HC-05 paired with a HC-06, powered by 2 arduino micros. Baud rate of sender is 30400 and receiver 9600(i have no idea why 30400 wont work on the receiver).
Having different Baud Rates of two units communicating using a serial interface is usually not a good idea. Why can't you set the sender baud rate to 9600? If you can, that's where I recommend you start. Also, if you could post your code, that would be great.
I bought a HM-15 BLE bluetooth module and successefully connected to Arduino. I am able to sent At commands and I would like to use it for scanning for iBeacons and get their major and minor.
Using AT+DISC? I can see the beacon address but I cannot connect to it and now I am stuck on how to retrieve major and minor
Can you help me? Here is the datasheet of the module:
http://www.elecrow.com/download/bluetooth40_en.pdf
Thanks
Bluetooth beacons do not require a connection and you read the identifiers directly from the advertisement.
Read section 19, Start a discovery scan, and learn how to read and decode the bytes in the discovered peripherals. The exact byte layout varies for different beacon types. For AltBeacon, an open source beacon variant, you can see the byte layout here: https://github.com/AltBeacon/spec
To decode a proprietary beacon format, you will need to learn how that beacon layout differs from the example linked above.
Old question, but just for the record, you can use AT-DISI?
This will scan for beacons, including iBeacons and also AltBeacons. The response from HM-10 will include RSSI for each.
PS: I'm assuming HM-15 and HM-10 operate the same way. Probably not exactly a fully reasonable assumption.
How do I send a string output from a DAQ Board (NI- USB 6259) using LabVIEW? I want to send commands such as "CELL 0" or "READ" to a potentiostat device using LabVIEW.
Thanks
The 6259 doesn't do string output. It's a data acquisition board that's intended for reading/sourcing analog voltages or sending/receiving individual digital signals. It's not a communications device.
If you're really trying to send strings to this device, you probably need something more like an RS-232 or GPIB connection.
As eaolson said a DAQ is not intended to control devices. However it is an interesting project to enter the guts of the communication protocol. Doing it with a DAQ would require to:
Identify the protocol (GPIB or RS-232)
Make your cable from the DAQ output connector
For each command, generate the waveform in LabVIEW, by using the letters' ASCII code, stop bits, etc. This is the funniest part (INMHO, but I understand it's not everybody!)
Send it (using DAQ analog write VIs, you should find many examples for this)
The oscilloscope will be your best friend