I'm developing a side-scan tide-gauge, using a cheapo laser "tape measure" ( lot of very clever tech squashed into a tiny hand-held unit) , hacking the SPI coding from the micro to the chip-on-glass LCD decoder driver of the display, to deliver to a pc. I live near a tidal river and the gardens back on to the river but only about high tide, mud otherwise, and lowest low tide is about 120m away from land, so distance measurer set to a downwards acute angle on the land, pointing out to the river. The output beam passes thru a small hole bored in a 6 inch glass lens and the increased capture return signal is processed as normal by the tape measure. Set at an acute angle, millpond water is a poor reflector but with the pierced lens and all set in a stout cylinder, that part works excluding direct in line sunlight, tide height then is related to the inverse of the measured path length. Response improves in the practicle situation of ripples on the surface, effect of small waves in a windy condition, I don't yet know. Using a basic pulse analyser and PulseView , I've cracked the hacking of the LCD coding for (Lidl) Parkside PLEM 50 (50m range ), to eventually use a Lomvum LV 120 (120m range) unit. The LCD panel with on-glass chip is made by SZYCLCD.COM and ident YGFB178004-A1 on the .5mm spacing ribbon and I know by swapping LCD ribbons between each, they are compatible between both devices , completely different external and internal appearance, but same STM micro and LCD coding, perhaps not the "J" string in the below. I have a Pi to play with , is the next stage , to interface the laser unit to a pc, replacing the pulse analyser , which requires saving to text file and word-processing to extract the data such as at the end here. First point is whether Pi GPIO will be fast enough to capture, or I'll have to try something else. The pulse analyser set to 2MHz was too slow a sample rate and 12MHz was perhaps higher than necessary, I can zero-in on that of course. I've been looking at
After the powerup of the laser unit, ignoring fist page, the code to the LCD on pressing "measure" is the following 4bit code for the main single row display (4 numeric rows plus anunciators in total) reading of 22.136 (m) where J=
4,F,D,8,8,D,D,4,1,E,8,C,6,0,C,2,A,0,2,0,5,0,9,2,C,B,1,1,1,1,1,1,1,1,6,0,7,C,8,0,0,0, K= 3,0,0,0,0,0,0,0,0,0,0,0,0,0, L= 2,0,0,0,4,0,7,0,8,0,0,8, N=2,0,A,0,0,8,4,0,8,0,0,4, P=0,0,0,0,0,0,0,0,8,0,0,0, q=8,A,0,0,0,8,F,0,8,0,0,C, r=,0,4,0,5,0,8,0,0,8, s=0,0,8,4,0,8,0,0,4, t=0,0,8,F,0,8,0,0,C, u=0,0,0,0,0, Z= 5,0,0,8,B,0,8,0,0,C repeated strings of code for 0 to 50m at least 22.136 (metres) on LCD SPI-hex stream , for the relevant in measure mode 3 data lines JKLKNKqKPK 6,9,F,rK E,5,A,sK 8,7,5,Z,K C,1,5,uJK(q sometimes contains F, sometimes B instead , reason unknown)
so required extracted data is
6,9,F E,5,A 8,7,5 C,1,5where rank 6E8C is the mm (thousandths) = 6mm
9571 is the cm data (combined tenths and hundredths) =13cm FA55 is the units and tens = 22m all 1 to 1 correlations so far seen Eventually I'll have a complete look-up table of these SPI hex conversions, 18 pairings only so far. I could post the set if anyone is interested, especially if they can find some sort of logic to the hex to decimal conversion (I've not found any relation) . In the LCD driver chip the look-up page would be SPI to 7-segment of course (7 segment not graphic dots)