@kennethlimcp When measuring the Vdc between the clock pin (D0) and ground, I got an average value of 0.6 to 0.7 V, the same for the data pin (D1) and ground. I was not able to get a steady reading but sometimes would witness a jump to around 3.3 V when a barcode was scanned while measuring the clock pin to ground. This did not occur every time, or maybe my hands werenât steady enough to tell.
@ScruffR I am going to get an old PS2 keyboard and give it a shot unless we solve it fairly soon. The scanner has no settings.
I think that a better long term solution might be a scanner that uses a laser instead of a camera as this is much faster and easier to use. The USB library I linked in my last post seems very well developed.
@kennethlimcp, first I have to admit, that I haven't had a look into the original library or your port, but from my (maybe outdated) knowledge of the PS/2 protocol I'm not too sure about the pull-ups (which tend to be smaller than the Arduino pull-ups).
As far as I recall the clock is generated by the keyboard (or scanner in this case) and for this reason I'd expect that the device is providing its own pull-ups (to +5V) and I'd go for pinMode(IRQpin, INPUT) otherwise you might actually end up creating a voltage devider (+5V -> pullup of deviced -> ? <- pullup of Core - which acts as "pull-low" in respect to the +5V <- +3.3V).
Even if it is not intended for the scanner, but the PS/2 protocoll would also allow for the host to send data to the device and for this purpose you'd either have to detachInterrupt() and alter pinMode(IRQpin, OUTPUT) or wire a dedicated output pin parallel to the IRQpin to pull the CLK line down for at least 60Âľs to signal the device to start creating a clock signal by which the host can sync its pushing out data to the device.
Since I haven't had a look at your port of the lib it might well be there already, but just to make sure
For more details about the protocol this link is nice and short
Thanks for the information! I see that the library is essentially using Pull_up in 2 different method but i decided to explicitly set it high just to be sure itâs set.
But looking at the feedback from the voltage measurement, the Pull_up somehow doesnât seem to be working. I would change the code to use no Pull_up and see again whatâs the voltage measurement like.
The hardware doesnât come with schematic so itâs hard for me to determine whether pull up resistors are used.
I never played with PS/2 before and did a simple port to make sure everything required is in place and ready to test with the actual hardware. Let me see what i can do on my side!
@btheye, USB interface is not that easier to interface with the core since the STM32F103B does not come with OTG capabilities. The Serial/PS2 version will be much easier to implement!
We just need to properly debug and see whatâs going on.
Do you happen to have an Arduino on hand? We can probably try and see whether it works well
@kennethlimcp, have you got an old PS/2 keyboard hanging around somewhere?
That would be the easiest way to check the library, even withouth the scanne HW.
But if you dare you could even mess a bit with a USB keyboard, since a lot of them still support PS/2 protocol if they detect that they are not connected to a USB port.
The wiring of such an adapter is pretty simple (see http://www.tomshardware.co.uk/answers/id-2213368/keyboard-usb.html)
I did this a while ago with a USB mouse and a Teensy
vKeyboardMouse_BT
A modded Logitech mouse that sends itâs PS/2 data stream to the Teensy which normally forwards it as USB-HID-Mouse package. This way it normally behaves like an ordinary mouse. But via a Bluetooth-SPP connection you can alter the normal mouse behaviour or even send Keyboard-/Mouse-HID-Packets/-Macros from any BT device to the mouse, which then forwards them to the host.
@bko, i need some help here. Seems like the #define INPUT_PULLUP is throwing up errors when i define it. That should be the reason why the pull_up voltage is not seen.
Am i defining it wrongly? Commenting out the #define worked fine!
placing #define INPUT_PULLUP in the .ino file compiled fine but checking with my multimeter, the pull_up was not implemented. Or should i say the âelseâ portion was used instead
@kennethlimcp I just gave it a initial try and still nothing is coming up on the serial monitor. In terms of Vdc, we are now seeing the correct behavior: ~3.3 V on both data and IRQ pins to ground. This is just their Vdc when no barcode is scanned. On the data pin, the standby voltage is 3.27 V and drops to approximately 3.20 V when the barcode scanner button is pressed and no barcode is scanned, it looks like it falls somewhere in between (3.24 V) the two voltages when the button is pressed and a barcode is actually scanned. A similar but smaller range situation is occurring with the IRQ pin, 3.288 V on standby, 3.280 V when button pressed with no code, 3.285 V when button pressed and barcode read. The code you send 13 hours ago is giving steady voltages of around 1.0 V on both data and IRQ pins to ground on standby.
I can get my Arduino Yun (loaned to a friend) this afternoon - would that be worthwhile? Should I still PM to debug? I can free myself up whenever you need.
Same as when I tried it the other day, lots of âďż˝â I think it might be time for me to try a new barcode scanner.
I could also try the Arduino Yun with the scanner - I will do that tonight. I have ordered a USB scanner as well because the scanning mechanism works better. Can you explain why it would more difficult to use a USB scanner?
@kennethlimcp We have serial output! My next objective is to make the data transmission occur over WiFi - I need to do some research on the best way to to accomplish this, options being: Spark.publish, Spark.variable, TCPServer/TCPClient, or UDP. I am not too concerned about byte limits, but I will need to push the data from the Spark Core by taking an action such as scanning a barcode (as opposed to a time-driven process), does that limit my options or should I delve into each to see which fits my needs best?