uploadImage issues

[l0rddarkf0rce]

Having the following issues when attempting to upload an image to the sensor. I've tried upload as jpg, png, and bmp. all with the same result.

1. Here is the error message I am getting
   Traceback (most recent call last):
   File "./authenticate.py", line 74, in
   f.uploadImage(filename)
   File "/usr/lib/python2.7/dist-packages/pyfingerprint/pyfingerprint.py", line 726, in uploadImage
   maxRowLength = max(map(lambda x: len(x), imageArray))
   TypeError: argument 2 to map() must support iteration

Here is the code that I am using to call uploadImage

filename = './'+empinfo[0]+empinfo[1]+empinfo[2]+'.jpg'
f.uploadImage(filename.lower())

2. If I hardcode the filename with just 3 characters in the name (otherwise I get the same as Unable to initialize Fingerprint sensor #1 above) when I call uploadImage I get the following message (I guess this one is not technically with uploadImage, but with convertImage.

Traceback (most recent call last):
File "./authenticate.py", line 75, in
f.convertImage(0x01)
File "/usr/lib/python2.7/dist-packages/pyfingerprint/pyfingerprint.py", line 854, in convertImage
receivedPacket = self.__readPacket()
File "/usr/lib/python2.7/dist-packages/pyfingerprint/pyfingerprint.py", line 301, in __readPacket
raise Exception('The received packet do not begin with a valid header!')
Exception: The received packet do not begin with a valid header!

Here is the code I use

f.uploadImage('./jjc.jpg')
f.convertImage(0x01)
f.storeTemplate(0,0x01)

[mefsantos]

Try to pull the most recent version.
The error in 1. points to a line of code prior to a modification where numpy is imported which is how imageArray is obtained.
And avoid using relative paths, try uploadImage(os.path.abspath(filename)) instead - don’t forget to import os.

[l0rddarkf0rce]

I've tried to pull the code at least 4 times and I keep getting the one that does not have the uploadImage functionality yet. In any case, got rid of the first error above. Now the problem is when I call convertImage here is how I am calling it: filename = os.getcwd()+"/"+empinfo[0]+empinfo[1]+empinfo[2]+".bmp" f.uploadImage(filename) f.convertImage(0x01) f.storeTemplate(0,0x01) I have tried to upload the image in bmp and jpg format both with the same result when I call convertImage

[mefsantos]

My bad, i thought bastian had already merged. Anyway, the latest version (of uploadImage) is here: https://github.com/bastianraschke/pyfingerprint/tree/167419e64c3cb53f96ea119a34fb383f728a7b63

However, if you get past the error 1. the issue is related with the communication with the sensor. In my case (with ZFM-20), whenever i get that error i usually try:

• confirm that the baud rate is the sensor's default: 9600 * 6 (57600). I have tried every possible value for N (1~12) but i can only communicate using N = 6, regardless of the connection (straight UART, usb to TTL converter, etc).

• use the provided examples to check if the problem is originated from your code.

• Verify the cable connections. First , the possibly swapped RxD and TxD: you should connect sensor RxD to the host's TxD, and sensor TxD to host's RxD. Check the GND cable. Then, check if the cables are properly connected. Sometimes, despite the sensor being turned on, i ended up with the same error message since i haven't soldered my setup. What i typically do is: disconnect GND, check the data wires and reconnect the GND.

[l0rddarkf0rce]

I found that after the uploadImage process says that the process finishes the sensor stays in some strange mode that I have not figured out yet. If I want to do anything after that I have to unplug the sensor and reconnect it. As for connection code I am using the sample code that you guys put together (I just do not believe in reinventing the wheel).

[mefsantos]

What is your setup? are you using a USB TTL converter? If so can it be the drivers? I usually connect the sensor directly to raspberry GPIO, however, i recently acquired a USB TTL converter and sometimes i obtained a message saying the sensor was "Busy" and had to restart the sensor. Since it never happened with the GPIO connection i assume its related with the converter drivers. I used these: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers.
Is your situation somehow related?

[l0rddarkf0rce]

i am using a usb converter (i can post exact model when i get home later tonight) and everything works fine as long as i don't try to upload an image. i can register fp, delwte fp, authenticate against the sensor etc. and no problems. ⁣Sent from TypeApp ​

…

On Feb 26, 2019, 09:03, at 09:03, mefsantos ***@***.***> wrote: What is your setup? are you using a USB TTL converter? If so can it be the drivers? I usually connect the sensor directly to raspberry GPIO, however, i recently acquired a USB TTL converter and sometimes i obtained a message saying the sensor was "Busy" and had to restart the sensor. Since it never happened with the GPIO connection i assume its related with the converter drivers. I used these: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers. Is your situation somehow related? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #68 (comment)

[l0rddarkf0rce]

Here are the details of the setup...

Raspberry Pi 3 B+

USB to TTL Adapter, USB to Serial Converter for Development Projects - Featuring Genuine FTDI USB UART IC ‘FT232RL’ (https://www.amazon.com/gp/product/B075N82CDL/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1)

Green Light Optical Fingerprint Reader Sensor Module for Arduino Mega2560 UNO R3 (https://www.amazon.com/gp/product/B07551XV2T/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1)

[mefsantos]

I was able to reproduce the issue using the converter. Somehow, using GPIO it doesn't happen.
In fact, there were two miss-indented lines, which should not be the cause of this issue.

However, after performing some tests and noticing some corrupted images (last rows) i went back to read the sensor specs where they say only 4 bits of the pixel are transferred (but do not specify if it SHOULD be for both, upload and download) and two adjacent bits forming the byte to be transferred, which I am also not sure it is related with the problem.
Anyway, the only way to be sure is trying to change the implementation.

I think i can't help you any further (for now) since i only recently started fooling around with the sensor.

[l0rddarkf0rce]

No problem, I am glad to see that I was not loosing what little I have left of my mind. I was able to do what I needed without using the image at all. What I am doing now is using the characteristics and going from there. Save my self a step. Also, if you need a guinea pig to test new code, just drop me a line and I'll be happy to test. Once again, many thanks for all the good work and your help. +-------------------------------------------------| Jose J. Cintron| [email protected]|| "Time is the fire in which we burn..."+------------------------------------------------- On Wednesday, February 27, 2019, 2:22:37 PM EST, mefsantos <[email protected]> wrote: I was able to reproduce the issue using the converter. Somehow, using GPIO it doesn't happen. In fact, there were two miss-indented lines, which should not be the cause of this issue. However, after performing some tests and noticing some corrupted images (last rows) i went back to read the sensor specs where they say only 4 bits of the pixel are transferred (but do not specify if it SHOULD be for both, upload and download) and two adjacent bits forming the byte to be transferred, which I am also not sure it is related with the problem. Anyway, the only way to be sure is trying to change the implementation. I think i can't help you any further (for now) since i only recently started fooling around with the sensor. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.