Capacitive Touch Sensor! Need help with HEX communication.

Thread Starter

Jebranakh

Joined Jan 19, 2020
5
Hello everyone.
I have been developing a fingerprint lock and successfully tested the proof of concept. I am planning to launch its beta version but before that I bought a finger print sensor( the manual is attached, refer to page 2), the communication was simple, even for a fresh mechanical engineer like me. simple Hex commands were to be sent and received between the microcontroller( any MC with UART) and the fingerprint module. I tried everything I could and no response from the finger print module came. I used an arduino to test the finger but will use STM8s103 in beta version. The manufacturer was very helpful and provided everything I needed but somehow I could not make it work. I have also attached the demo software and codes provided by the manufacturer with this thread. If anyone take a look at the manual and code and suggest a code to send and receive the HEX codes, It would really help me out.
Thanks a lot.
 

Attachments

AlbertHall

Joined Jun 4, 2014
9,039
The serial protocol depends on both ends using the settings: baud rate, number of bits, number of stop bits, flow control, etc.
The FPM can operate at various settings for these items but I can't see how these are set within the files you posted.
Until the settings agree you will get no response.

Also, the voltages used and the polarity of the data must match. The FPM expects 3V signals but I could find nothing on the polarity of the data.

Do you have any other files which might contain this information?
 

Thread Starter

Jebranakh

Joined Jan 19, 2020
5
The serial protocol depends on both ends using the settings: baud rate, number of bits, number of stop bits, flow control, etc.
The FPM can operate at various settings for these items but I can't see how these are set within the files you posted.
Until the settings agree you will get no response.

Also, the voltages used and the polarity of the data must match. The FPM expects 3V signals but I could find nothing on the polarity of the data.

Do you have any other files which might contain this information?
Sorry, I didn't shared the pin out and electrical spec, the manufacturer provided that too, I will share that too with this reply. I provided 5v and connected the Tx and Rx to the Rx and Tx of the Arduino Uno, respectively. There is no problem in the connections as I have done this hundreds of time with lots of modules, but this was the first time I was sending HEX codes. I asked many relevant people to see the page 2 of the attached manual of FPM and at least tell me the sequence of the sending HEX codes, I used Serial.write() and Serial.Print() but nothing worked. The manufacturer even provided their libraries and code which I tried to run it in Arduino IDE but I guess I am not that good at setting codes.
 

Attachments

I just want to make a few comments and share this https://www.electronicwings.com/arduino/usart-in-arduino-uno page.

It says you can't have two serial interfaces at the same time.

TTL serial normally is inverted.

I can see some very frustrating things happening if the reader isn't reset. e.g. reset the module and clear the character buffer. i.e. read until there is nothing there. There is a reset pin on the interface and I would suggest using it.

HEX is just a representation. Let's take ASCII 65 is a capital A.

128 64 32 16 8 4 2 1
0 1 0 0 0 0 0 1 that's binary
break into 2 nibbles of 4 bits we get 41h

You might have to write a program to print the 8-bit returned values in hex.
Tricks are like take the 8 bit unsigned number and AND it with 15.
Take the 8 bit number an shift right 3 and AND with 15.

If the result is between 0 and 9 add 48; print Char(48+n)
If the result is between 10 and 15; add 65; print char (65+n)

48 should be the ASCII vale for "0" and 65 the ASCII value for an "A"
You will get 0-9 and A-F.

Casually looking through the specs, you need checksums to be right too. That adds more complexity.
The easiest way to do checksums is to use XOR. You can also add, but watch out for overflows/

Byte order was important.

You do need to reset the interface.
You do need to have the baud and parity right.
You do need to find a command to send that has a known response.
I think there was one.

Watch out for the order of characters.
 

pmd34

Joined Feb 22, 2014
503
Have you checked that you are using 57600 Baud by default? I use "real term" https://sourceforge.net/projects/realterm/
For doing serial coms. from my PC, though you need a cheap USB to TTL serial device, you can buy them cheaply from china. They are also very handy to keep an eye on what signals are actually going backwards and forwards. This would be a first step to see if you can get 2 way data going between your computer and the sensor, as you will also need some extra bits of programming like timeouts etc. when implementing a microcontroller to do it.

Generally the PC usb serial communication device is very forgiving with data timing, but Micro-controllers can be very fussy, and often do not receive the correct data unless the crystal frequency enables only a very small error in baud rate generation. In the ATmega data sheets in particular there is a section about the baud rate and the errors. For some of my projects I ended up inserting an 18.432 MHz crystal just to ensure 0% error on timing.
 

Thread Starter

Jebranakh

Joined Jan 19, 2020
5
Have you checked that you are using 57600 Baud by default? I use "real term" https://sourceforge.net/projects/realterm/
For doing serial coms. from my PC, though you need a cheap USB to TTL serial device, you can buy them cheaply from china. They are also very handy to keep an eye on what signals are actually going backwards and forwards. This would be a first step to see if you can get 2 way data going between your computer and the sensor, as you will also need some extra bits of programming like timeouts etc. when implementing a microcontroller to do it.

Generally the PC usb serial communication device is very forgiving with data timing, but Micro-controllers can be very fussy, and often do not receive the correct data unless the crystal frequency enables only a very small error in baud rate generation. In the ATmega data sheets in particular there is a section about the baud rate and the errors. For some of my projects I ended up inserting an 18.432 MHz crystal just to ensure 0% error on timing.
I did got TTL serial device and set the baud rate to mentioned value. It would still have problems connecting with demo app provided by the manufacturer. I think I might have fried the FPM while soldering the wires on it, because even if my code was faulty it still would connect with the demo App or at least show connectivity. I guess I have to buy a new one and try again.
 

Thread Starter

Jebranakh

Joined Jan 19, 2020
5
I just want to make a few comments and share this https://www.electronicwings.com/arduino/usart-in-arduino-uno page.

It says you can't have two serial interfaces at the same time.

TTL serial normally is inverted.

I can see some very frustrating things happening if the reader isn't reset. e.g. reset the module and clear the character buffer. i.e. read until there is nothing there. There is a reset pin on the interface and I would suggest using it.

HEX is just a representation. Let's take ASCII 65 is a capital A.

128 64 32 16 8 4 2 1
0 1 0 0 0 0 0 1 that's binary
break into 2 nibbles of 4 bits we get 41h

You might have to write a program to print the 8-bit returned values in hex.
Tricks are like take the 8 bit unsigned number and AND it with 15.
Take the 8 bit number an shift right 3 and AND with 15.

If the result is between 0 and 9 add 48; print Char(48+n)
If the result is between 10 and 15; add 65; print char (65+n)

48 should be the ASCII vale for "0" and 65 the ASCII value for an "A"
You will get 0-9 and A-F.

Casually looking through the specs, you need checksums to be right too. That adds more complexity.
The easiest way to do checksums is to use XOR. You can also add, but watch out for overflows/

Byte order was important.

You do need to reset the interface.
You do need to have the baud and parity right.
You do need to find a command to send that has a known response.
I think there was one.

Watch out for the order of characters.

I tried to send Binary instead of HEX too, but may be the order was not correct, what you mentioned is exactly what has been advised by the manufacturer too. What I suspect is that may be I have fried the FPM while soldering wires on it, because it wasnt even connecting with the Demo app provided by manufacturer. I shall order a new one and try again from the scratch.
 
Top