I'm building a linux-based cashless device and trying to achieve communication with VMC in vending machines over UART directly without needing additional hardware adapter to convert between 8-bit and 9-bit frame data.
I'm only using the cashless device, no intention to connect any other peripheral to the VMC.
I read questions asked about this before, some of them stressed on the need to an adapter, others suggested possible hacks to achieve the 9-bit to 8-bit conversion, but still can't find a confirmed working and stable solution.
My question is, Is it possible (and reliable) to achieve this using a pure software solution? and how?
Thanks
Yes.
The 9th bit is a control bit. It will show if the data is to be interpreted as an address or as data. If you are communicating with one device and sending only data you want to strip the 9th bit out and only look at data frames. Check and see if it's always zero:
If controlBit = 0:
ProcessData(byte)
Else:
print("This is an address: " + byte)
EDIT:
Many people have reported that your connection will not be stable without special hardware due to timing problems.
Instead of reinventing the wheel you can use opensource code as a starting point.
https://github.com/mhaqs/vendiverse/wiki/Programming-the-VMC
This way you don't have to make the same mistakes over and over again.
Related
Using BlueZ, which
is the official Linux Bluetooth stack
I'd like to know which of the below two methods are better suited for detecting a device's presence in the nearby.
To be more exact, I want to periodically scan for a Bluetooth device (not BLE => no advertisement packets are sent).
I found two ways of detecting it:
1.) Using l2ping
# l2ping BTMAC
2.) Using hcitool
# hcitool name BTMAC
Both approaches working.
I'd like to know, which approach would drain more battery of the scanned device?
Looking at solution #1 (l2ping's source):
It uses a standard socket connect call to connect to the remote device, then uses the send command to send data to it:
send(sk, send_buf, L2CAP_CMD_HDR_SIZE + size, 0)
Now, L2CAP_CMD_HDR_SIZE is 4, and default size is 44, so altogether 48 bytes are sent, and received back with L2CAP_ECHO_REQ.
For hcitool I just have found the entrypoint:
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to);
My questions:
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
shall I reduce the l2ping's size? What shall be the minimum?
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
To answer your questions:-
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
l2ping BTMAC is the more suitable command purely because this is what it is meant to do. While "hcitool name BTMAC" is used to get the remote device's name, "l2ping" is used to detect its presence which is what you want to achieve. The difference in power consumption is really minimal, but if there is any then l2ping should be less power consuming.
shall I reduce the l2ping's size? What shall be the minimum?
If changing the l2ping size requires modifying the source code then I recommend leaving it the same. By leaving it the same you are using the same command that has been used countless times and the same command that was used to qualify the BlueZ stack. This way there's less chance for error and any change would not result in noticeable performance or power improvements.
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
Yes your assumption is correct. According the Bluetooth Specification v5.2, Vol 4, Part E, Section 7.1.19 Remote Name Request Command:
If no connection exists between the local device and the device
corresponding to the BD_ADDR, a temporary Link Layer connection will
be established to obtain the LMP features and name of the remote
device.
I hope this helps.
I'm in a situation where we are hooking up to a device that may speak a variety of different baud rates depending on model. Some of which may be non-standard, like 10000, but that's another problem for another day.
Ideally I could use Qt to auto detect the baud rate, but from my research that's likely not possible for a few reasons, which I'm okay with. However, is there any native Linux based method to auto detect the baud rate of the connected device? Even a 3rd party open source application could suffice.
Linux serial drivers don't support autobauding, because most hardware doesn't support it, because there's no agreement on how it might work. It's highly application-specific.
If you're using FTDI serial adapters, then most of them support the bit-bang mode, and you should use them as a digital oscilloscope in such a mode to get a bitstream that's very easy to autobaud on.
On other devices, the simplest way towards autobauding is to set the device to 2-3x the highest baudrate you expect, then treat the input data like a chunked digital oscilloscope, taking account of error bits, and use heuristics to detect the baud rate. It will succeed in a surprising number of cases, but you must get the statistical model of the data source right. I don't know of any pre-canned solutions for that.
Some additional kernel support could be had to better timestamp the input from the UART (whether hardware or USB) and thus decrease the uncertainity in your data and thus the number of samples you need to take to detect baud.
Some of which may be non-standard, like 10000, but that's another problem for another day.
No biggie. I figured it out 16 years ago :) This is the answer you're looking for. If you think that the API is sick as in very, very sick, then you'd be right.
I am currently working on a project which aim to detect Bluetooth and decode Bluetooth packets (I use a Hack RF One to make the detection). I have made a Gnuradio Flowgraph in order to demodulate Bluetooth signal and I am trying to decode visualy the packets by searching a Bluetooth frame on a binary file.
Unfortunately, I didn't succeed to recover a clear view of the Bluetooth signal. To be precise, I am pretty sure that I detect Bluetooth on my sinks but when sending this to a Clock Recovery + Binary Slicer blocks, I am unable to recover interresting data in the binary file (especially the MAC adress of the sending device, which is part of the a Bluetooth packet). Moreover, I would like to know what type of network layer (physical, transport, baseband...) is intercepted in this type of process. In my case, I aim to intercept baseband layer packets.
Additionaly, I am interrested in knowing how to use the gr-bluetooth because I can't find a lot of documentation concerning this block. I think this can be interresting for the development of my project.
Could you please, give me your view, opinion about this problem ? I am stucked at this stage without knowing the exact origin of my issue. (Here is my flowgraph GnuRadio_Flowgraph and a screenshot of one of my Bluetooth detection Detected signal at 2.402GHz).
Thank you very much,
You probably need an ubertooth instead https://www.sparkfun.com/products/10573
I read that the bluetooth frequency skipping is spread wider than the HackRF can read, so at-best, you're going to miss 75% of frames if you only have one hackrf connected.
I'm using a Virtex 5 FPGA and want to have a few +5/0 I/O pins to communicate with a microcontroller. The only peripherials I've used on the board so far are pushbuttons and switches and no one I've asked seems to know the simplest way to do this I/O. I've looked around the board specification but haven't found any simple way of doing it. I would appreciate any advice you might have.
This is not an easy thing to do. If you don't have the schematic of the board, then you need to get volt meter with some fine pitch probes and reverse engineer the board.
It is pretty easy if you have 2 boards, with one board it can be really hard since the BGA signals may not be connected to a via and therefore not available on the bottom of the board, and even if they are, then you don't know exactly which pin they are connected to. But with some luck, you can find them since the VIA can only be connected to 4 possible pins surrounding it!
The first thing you need to do is to identify your chip, find the BGA print of the IC from Xilin'x web site.
If your board has some buttons already, then if you are lucky, those signals may be routed to the pins of the FPGA that are available on the bottom of your board. Here are the things you need to do:
Make sure you have good ESD protection to perform these test
Put your voltmeter into 'buzzer' mode
Check the pins of your connector and find out how it is connected, see if there is a pull-up and/or pull-down resistors on the board
when you find the 'active' pin of your connector, start connecting the other probe to the VIAs one by one
When you hear a buzz, make a note of the position (guess or measure the distance between the side of t he IC and the location of the via)
Identify the 4 possible pins that the signal can be connected to
Write a code to get all those 4 signals and connect them to ChipScope
In Chip Scope, capture all 4 signals and see which one is the one with the right connection!
alternative, you can create a design with inputs only, capture all the inputs and put them into a memory block and create a trigger logic to capture all the signals whenever any of the inputs changes, after lots of work and analysis, you will find the correct pins.
Anyway, these are just crazy ideas since this is a really difficult thing to do without having the PCB info of the board.
Good luck with your hacking.
I have a device that takes low current 3-12v input signal to do it's magic and I would like to interface it to my linux box. What kind of options do I have on this? It would be great to have some low-cost possibly user-space solution.
If I understand right, you need to control your box by changing 3-12v input signals to it. Here's the choices I can think of from the top of my head:-
a: Using RS232 serial handshake lines. RTS/CTS can usually controlled programatically as "on/off" signals without driver development using IOCTL calls.
b: Use a "GPI dongle" such as the Advantech ADAM range. These typically take serial or TCP/IP inputs and convert them to suitable output signals.
c: You may be able to do something with a parallel printer port if your PC stil has such a thing.
As shodanex says, be aware that RS232 levels are NOT directly compatible with TTL/CMOS inputs so you may need some minor level shifting/clamping electronics to fix this.