4

I have a barcode scanner working on 433Mhz (FSK). Since this is a relatively old product and the PC software is not working with Windows 10's and I can't use the SDK anymore. I, therefore, have decided to make my own receiver hardware and a PC software accordingly.

I have disassembled the scanner and directly wired to a simple logic analyzer from the device's transceiver module. There is not much information about this module. But, I know pin-outs, their functions and "receives and transmit data packets at 36864 baud Manchester encoded".

So, I have opened the old program with an old Windows OS version and start scanning right after I clicked the start button on the Logic analyzer. Normally, the receiver has continuous reception regardless if I am using the scanner or not. We can consider this as other emissions in the environment.

As far as I discovered, there is a carrier detect signal leading the scan data and around this (beginning of the carrier detector after carrier detect signal) there are serial of bits looking like preamble with 0's (if I am not mistaken, because shouldn't that preamble always right after the carrier signal as part of the data?)

Logic analyzer Manchester setup:

enter image description here

And some output from the analyzer (you can ask more detailed look if you like):

There are two consecutive barcode scannings here.

enter image description here

I have tried several version of the settings. I tried to place some random numbers in the Preamble bits field or different bit rates, positive or negative edge, LSB or MSB but I couldn't get the analyzer decoded my signal. At least I would like to see the barcode I scanned somewhere in the data part.

I am not an expert on this encoding and RF communication but learning and I am reasonably enthusiast.

Any pointers would be greatly appreciated.

EDIT:

In order to be certain what's being really sent by the scanner, I have also recorded the transmit data from the source directly. I believe that it is giving more clue than the captured receive data. (There are two different barcode scannings included and placed one after each vertically in order to analyze/compare better)

enter image description here

EDIT:

Here is the transceiver module sitting on the main board as daughter board:

It is Telital RT14. Pins are marked in a red square where I hook-up them to the logic analyzer.

enter image description here

EDIT:

A diagram of how the RF device is connected to the barcode reading system.

enter image description here

Niteesh Shanbog
  • 711
  • 7
  • 21
Sener
  • 231
  • 5
  • 16
  • Do you need help understanding Manchester coding, or are you looking for a specific algorithm? – Cristobol Polychronopolis Dec 18 '18 at 13:55
  • I am not sure what I need here to find out decoding code. Or even It is possible. – Sener Dec 18 '18 at 19:00
  • https://en.wikipedia.org/wiki/Manchester_code will give you an overview. It's not too complicated...each 1 becomes a 01 sequence, and each 0 becomes a 10 (according to IEEE, others code the opposite polarity). There are algorithms widely available, from C to Matlab...google "manchester decoding." If you're looking at it on the scope, you can figure the clock scheme by recognizing that there's always a transition in the middle of a bit, but not always between bits. In fact, the motivation for this scheme is that it both removes DC content and guarantees transitions. – Cristobol Polychronopolis Dec 19 '18 at 15:43
  • Yes, I know this part. Even I apply this basic decoding rules, I couldn't see the scanned code e.g. A09-0003 at the presumed place within the pulses. You see yourself in my post how the transmitted data looks when the barcode is scanned. I can't still figure out how that code to be parsed in order to expose the scanned code. – Sener Dec 19 '18 at 15:58
  • It may not be so simple...there might be an error correcting code, interleaved with the data in a way to limit the effects of a blemish on the barcode or noise bursts in the RF, it may be compressed, and/or there may be noise (I'm not sure if the scanner interprets the message itself or just sends the raw scan). Theoretically, the line will stay in one state for either 27.127uS or 54.254us at 36864 baud, but I see more than two durations on your TX scan. Are you sure the encoding has been applied at the point you intercepted the TX signal? If so, it's something other than basic Manchester. – Cristobol Polychronopolis Dec 19 '18 at 16:15
  • I edit my post and add the RF module information. I am directly using the pins from the transceiver before logic circuitry/mcu. – Sener Dec 19 '18 at 16:33
  • since a mid bit cell state change is required for continuous data you cannot have more than two half bit cells at the same state. so once you see two half bit cells at the same state the next edge is at the half bit cell and you can decode from there, if this is continous data like IRIG 106 (where this is called biphase-l encoding). if it is bursty or has a packet structure (like MIL-STD-1553 which also uses this type of encoding) then that is even easier to decode as you dont have to search for a place to start decoding in a moving stream. – old_timer Dec 19 '18 at 20:55
  • your snapshots dont look remotely like manchester encoding. – old_timer Dec 19 '18 at 20:56
  • @old_timer, what you say now bugs me (not look a like manchester encoding). Maybe you are right, is not what I think. I talk from some documentation I found regarding to the barcode scanner product and says it is manchester encoding. Now, I don't know what to think anymore. What can I do to verify the type of encoding of the pulses then? – Sener Dec 20 '18 at 00:55
  • 2
    manchester encoding insures a transition density, state changes are strictly at either half a bit cell or a full bit cell apart in time, anything else is a protocol error. your signal clearly doesnt look like that as far as i can see from your pictures. now if you have bursty packets then the packets should still have this somewhat rigid look to them with lots of evenly spaced transitions.. so maybe you are looking at something else or at something that has been decoded to nrz-l (basic ones and zeros, no encoding), or other... – old_timer Dec 20 '18 at 15:34
  • When I look at some other documentation, I can see another remark regarding a PIC controller talking to the RF device; `Programmable OTP microcontroller which converts uart NRZ (start+data+stop) bits into radio output Manchester RZ data bits. It works at 3.6864 MHz.` Does that make any sense? – Sener Dec 20 '18 at 15:58
  • The RF signal is Manchester encoded, the UART signal is most likely not. – Lior Bilia Apr 09 '19 at 09:07
  • Although this does not look quite like manchester encoding, the apparent preamble looks suspiciously like the SDLC/HDLC frame symbol (0x7E);; if so, then there will be (at least) bit stuffing going on to prevent data fields from having this sequence. – Peter Smith Apr 09 '19 at 09:55
  • @Peter, thanks for your input, appreciated. I still gather bit and pieces in order to decode that data. However, I have also started to suspect that the data is `compressed` in someway as it is not really demonstrating Manchester encoding although the limited datasheet says so. – Sener Apr 09 '19 at 13:07

0 Answers0