TOF10120 Laser Range Sensor Module

Haroen

Member
I've connected a TOF10120 with my circuit and tried to continuously read distances with both serin and (H)i2c by my code without succes.
* The serial values are invalid distances.
* The i2c gives me just 1 value and then stops.
I like to get serin and i2c both working but how?
24294
Code:
#PICAXE 08M2
SetFreq M8

INIT:
     i2cslave $52, i2cslow, i2cbyte

Main:
    'SERIAL
    SerIn C.4, N9600_8, w0
    'I2C
    writei2c 0,(%01000111)
    'VISUALISATIE
    Debug
Goto Main
 

AllyCat

Senior Member
Hi,

My Chinese isn't good, but it looks to me as if the I2C Slave address is $A4 not $52. Also, you should use the PICaxe as a MASTER, not a Slave. What was the one value that you received?

Do you expect to receive a Word serially? The W0 will receive only one Byte. For a Word, use B0 , B1 or B1 , B0 , depending which byte is sent first.

Cheers, Alan.
 

Haroen

Member
I now learned Chinese a bit to find the Slave address $A4.
But not enough to know what to expect to receive serially.
To change to MASTER it had to be Hi2c and values freeze b2=b3=255.
Code:
#PICAXE 08M2
SetFreq M8

INIT:
    hi2csetup i2cmaster, $A4, i2cfast, i2cbyte

Main:
    'SERIAL
    SerIn C.4, N9600_8, w10
    'I2C
    hi2cout 0x00,(0x01)
    hi2cin 0,(b3,b2)
    'VISUALIZE
    Debug
Goto Main
 

AllyCat

Senior Member
Hi,

With the I2C bus, a returned value of "255" usually indicates "No Reply", so you probably don't have it working yet. What is the reply on the Serial input now (which will still be only ONE BYTE stored into w10) ?

Why did you start a new thread when there is useful information in your earlier threaad ? The DroneBot Workshop probably gives as much information as is easily available. In particular:

"The real action in this sketch occurs in the SensorRead function. If you step through this function you’ll see how the I2C bus is used to contact the sensor, request a reading and add the result to a data buffer."

So you will need to determine what "command" must be sent. It looks as if it might just be HI2CIN (0) and then HI2CIN (b0 , b1) to read the data, but I have no way to test that.

Cheers, Alan.
 

Haroen

Member
I2C maybe address not as datasheet specified but like this video where he uses TeraTerm to figure out the address.
I tried TeraTerm too but it's not clear how he did it and what he selected within the program.
Does PE has this feature too?

The reply on the Serial input indeed still only ONE BYTE stored into w10 are values from 0 to 254.

Started a new thread from that 5 months old thread not to bump the thread.

First HI2CIN (0) and then HI2CIN (b0 , b1) gives a Syntax Error.
 

AllyCat

Senior Member
Hi,
Does PE has this feature too?
Not directly, but see post #4 in this code snippet. There doesn't seem much doubt that its Slave address for a PICaxe should be $A4 .
The reply on the Serial input indeed still only ONE BYTE stored into w10 are values from 0 to 254.
So what value are you expecting? One byte can only be 0 - 255 and you've only asked for one variable (byte). Serial data is always in (single) bytes.
Started a new thread from that 5 months old thread not to bump the thread.
First HI2CIN (0) and then HI2CIN (b0 , b1) gives a Syntax Error.
"Bumping" normally applies only to posting with no additional information. There's no harm in adding to a previous thread (particularly if it's your own).
Sorry, a typo, try:
Code:
hi2csetup i2cmaster, $A4, i2cfast, i2cbyte
HI2COUT (0)
HI2CIN (b0 , b1)
Cheers, Alan.
 

Haroen

Member
Nice work with the I2C scanner, I would love to try it! Not sure how to use it though.
I will stick to $A4 for now.

I would expect a b0 and b1 that with some calculation will lead to the distance in mm.
With only 1 byte 0-255 for 10-180cm some conversion will be needed to get mm from the serial values.

I did some reading of KARAMBA and BALDWINK threads first before starting this thread not knowing if what I posted here was additional info.
Sorry, I can't take credit of their threads because those where not my own.

I tried the last code post #6 in post #5 and it gave me a Syntax Error.

Is it possible to extract the PICAXE code needed from the working Arduino code?
* https://dronebotworkshop.com/laser-vs-ultrasonic-distance-sensor-tests/
* https://community.particle.io/t/sketch-modify-for-tof10120-sensor/56525
* https://surtrtech.com/2019/03/18/easy-use-of-tof-10120-laser-rangefinder-to-measure-distance-with-arduino-lcd/
 

AllyCat

Senior Member
Hi,
I tried the last code post #6 in post #5 and it gave me a Syntax Error.
The first two lines are optional (to ensure the PE is set up correctly) :

24296


I would expect a b0 and b1 that with some calculation will lead to the distance in mm.
With only 1 byte 0-255 for 10-180cm some conversion will be needed to get mm from the serial values.
From the dronebots link, for the I2c that appears to be correct. But the RS232 appears to be direct ASCII characters, so the output could be:
"2" , "0" . "0" , "0" , "m" , "m" , <CR> , <LF> or decimal : 50 ,48 , 48 , 48 , 105 , 105 , 13 , 10 ...... <pause>
The screenshot from the video suggests that the data strings are not of constant length (number of bytes) and also that the sensor looks fairly "useless" above about 700mm. I also have doubts about the "1mm" reports !

24297

PICaxe can struggle with 9600 baud from external hardware. It is definitely possible by using HSERIN, "special" commands (such as PEEKSFRs) and probably interrupts, but that's quite "Advanced" programming. You could try the following but it's far from guaranteed to work:
Code:
#picaxe 08m2
#no_data
symbol qualifier = 10            ; Try also "m" , 13 , or double qualifiers : "m","m"   or  13 , 10 , etc.
Setfreq m32 
do  
    SerIn C.4, N9600_32, (qualifier), b2,b3,b4,b5,b6,b7
    DEBUG    ;    Or better a SERTXD command
loop
Nice work with the I2C scanner, I would love to try it! Not sure how to use it though.
Just copy the whole program into PE6. You may need to change the top few lines, for example the PICaxe type. Then try a Syntax check and then programming the PICaxe. There might be some "error" messages to help run it.
Is it possible to extract the PICAXE code needed from the working Arduino code?
Possibly for very "simple" code, however I won't do it. But generally the issues are with Hardware compatibility, or information buried deep in a "Library", rather than the raw code.

Sorry about the large screenshots, that seems to be the default forum setup. :(

Cheers, Alan.
 

neiltechspec

Senior Member
Just a couple of obervations on the subject,

As original code attempt was running the 08M2 at 8Mhz

Shouldn't the i2cfast be i2cfast_8, could it be running it too quick without the _8.

For 9600 serial in, I had far more success running the picaxe at 16Mhz, seemed more reliable.

Neil.
 

Haroen

Member
The code with the hi2cin 0,(b0,b1) command gives 255 twice in debug.

In the PE debug screen b0 is like (~, a, †, x,f,',à,l,etc) that is not the expecting ASCII characters like 0-9 and "m" or maybe "c" for cm too.

Above 700mm the reflected light is less bright and has trouble with surrounding light I think.
I will test it when I get it working and will give here my findings also about the "1mm" reports .
(Although, for most of my applications 700mm is enough.)

I tried the Do-Loop code first with all suggested the qualifiers 10, 13, "m" and "m","m" getting "Debug-waiting for data...".
Then I tried without the qualifier (yet unknown ) and also extended the bytes to b0-b11 and all variables get debug values now but weird AISCII!
Then I tried with a frequent visible ASCII character "=", where debug values got more stable but not stable enough.
Here are screenshots of several debug values to find out how to get a correct distance value.
24299

Thanks for the Arduino2PICAXE code explaining, I always wondered about that.

@neiltechspec
I tried i2cfast_8 too but without success. Thanks for the input.
9600 serial in, more success running the picaxe at 16Mhz is true, even better m32, thanks.
 

AllyCat

Senior Member
Hi,
The code with the hi2cin 0,(b0,b1) command gives 255 twice in debug.
No, that is probably not correct, First you must request a reply which might be hi2cOUT (0) . Then (in another command line) you ask for two values which could be hi2cIN (b2,b3). A value before the brackets is probably NOT needed, because the chip does not appear to use a register address.

Neil is correct, the I2CFAST may be too fast. That's usually assumed to be 400 kHz, but I think I saw the TOF10120 specified as only 100 kHz. For such a small amount of data (particularly with a PICaxe) there's no harm in using I2CSLOW which might work better.

Even with SETFREQ m32, it's quite possible that the PICaxe cannot receive 9600 baud reliably, if the ASCII characters are transmitted too close together. But have you tried both N9600_32 and T9600_32 polarities as I haven't seen it specified anywhere?

Cheers, Alan.
 

Haroen

Member
Ah, my bad in that command the "0," should not be there hi2cin 0,(b0,b1), rest of code was the same, sorry.
Still getting 255 twice in debug. Also when I use I2CSLOW .

YES, and it worked SERIAL when switching to T9600_32 giving me distances in perfect mm measured on a fernier calipher up to 150mm!
I noticed that the reflecting surface has to be perpendicular to the laser otherwise it is 1 to 2mm difference within 150mm.
It seems to freeze above 2000mm with 3 to 4mm difference. But it's then very difficult to keep it perpendicular!

24302
 

AllyCat

Senior Member
Hi,

It's probably worth changing the qualifier to 13 (i.e. <CR>) , then b0 should always be 10 (i.e. <LF> ) to give a check that no digits have been missed. For the program to give a genuine "numerical" distance, it will need to "search" through the list of digits to find the first "m". Then it can work "backwards" through the digits (i.e. bytes) for 1mm , 10mm , 100mm and 1000mm (if they have been transmitted) to build up the distance in a single Word.

It doesn't appear that you have EVER received ANY valid data over the I2C bus? So you probably need to check the Hardware, for example you have fitted Pull-Up resistors haven't you ? It should be worth trying the I2C Bus searching program (in post #4) which I linked above (in Post #6). Just "Select All" of the text in the Code window and "Copy", then in PE6 (or PE5) "Paste" into a "File > New > New Basic" window. You should only need to change the name in the first text line from PICAXE14 to PICAXE08 and Download and Run the program as usual. It should be able to check for (and supply) missing pullup resistors, and some other hardware faults.

Cheers, Alan.
 

stan74

Senior Member
Looks like an interesting device. I liked the VL0X laser range finder. I think I'll get a TOF10120 to try.
edit...just ordered one from banggood
 
Last edited:

Haroen

Member
SERIAL
To change the qualifier to 13 and to find the first "m" for correct display of digits as a distance is all true depending on which project to use.
In a lathe or mill DRO system it should be displayed as above xxxxmm.
In an EndSensor it only needs the distance value to act on.
In other projects maybe just a distance difference is required.

I2C
I removed the TOF10120 from my circuit(with 2x 4K7 PullUps).
Then I connect it to this circuit on P1 first 4 pins:
*C.4 to Red wire
*SerialOut to Black wire
*Scl to Purple wire
*Sda to Green wire
24305
Scanner results if circuit is correct?
Code:
SCL= 1  SDA= 2  V+= 0  GND=0

Vpsu = 4.96 Volts
Looking for Devices ...

   0  2  4  6  8  A  C  E      0  2  4  6  8  A  C  E
0 XX XX XX XX XX XX XX XX   1 10 12 14 16 18 1A 1C 1E
2 20 22 24 26 28 2A 2C 2E   3 30 32 34 36 38 3A 3C 3E
4 40 42 44 46 48 4A 4C 4E   5 50 52 54 56 58 5A 5C 5E
6 60 62 64 66 68 6A 6C 6E   7 70 72 74 76 78 7A 7C 7E
8 80 82 84 86 88 8A 8C 8E   9 90 92 94 96 98 9A 9C 9E
A A0 A2 A4 A6 A8 AA AC AE   B B0 B2 B4 B6 B8 BA BC BE
C C0 C2 C4 C6 C8 CA CC CE   D D0 D2 D4 D6 D8 DA DC DE
E E0 E2 E4 E6 E8 EA EC EE   F XX XX XX XX XX XX XX XX

Device found at 10 =   (Not Programmed)
Device found at 12 =   (Not Programmed)
Device found at 14 =   (Not Programmed)
Device found at 16 =   (Not Programmed)
Device found at 18 =   (Not Programmed)
Device found at 1A =   (Not Programmed)
Device found at 1C =   (Not Programmed)
Device found at 1E =   (Not Programmed)
Device found at 20 =   (Not Programmed)
Device found at 22 =   (Not Programmed)
Device found at 24 =   (Not Programmed)
Device found at 26 =   (Not Programmed)
Device found at 28 =   (Not Programmed)
Device found at 2A =   (Not Programmed)
Device found at 2C =   (Not Programmed)
Device found at 2E =   (Not Programmed)
Device found at 30 =   (Not Programmed)
Device found at 32 =   (Not Programmed)
Device found at 34 =   (Not Programmed)
Device found at 36 =   (Not Programmed)
Device found at 38 =   (Not Programmed)
Device found at 3A =   (Not Programmed)
Device found at 3C =   (Not Programmed)
Device found at 3E =   (Not Programmed)
Device found at 40 = Expander PCF8574
Device found at 42 = Expander PCF8574
Device found at 44 = Expander PCF8574
Device found at 46 = Expander PCF8574
Device found at 48 = Expander PCF8574
Device found at 4A = Expander PCF8574
Device found at 4C = Expander PCF8574
Device found at 4E = Expander PCF8574
Device found at 50 =   (Not Programmed)
Device found at 52 =   (Not Programmed)
Device found at 54 =   (Not Programmed)
Device found at 56 =   (Not Programmed)
Device found at 58 =   (Not Programmed)
Device found at 5A =   (Not Programmed)
Device found at 5C =   (Not Programmed)
Device found at 5E =   (Not Programmed)
Device found at 60 =   (Not Programmed)
Device found at 62 =   (Not Programmed)
Device found at 64 =   (Not Programmed)
Device found at 66 =   (Not Programmed)
Device found at 68 =   (Not Programmed)
Device found at 6A =   (Not Programmed)
Device found at 6C =   (Not Programmed)
Device found at 6E =   (Not Programmed)
Device found at 70 = Expander PCF8574A
Device found at 72 = Expander PCF8574A
Device found at 74 = Expander PCF8574A
Device found at 76 = Expander PCF8574A
Device found at 78 = SSD1306 OLED
Device found at 7A = Expander PCF8574A
Device found at 7C = Expander PCF8574A
Device found at 7E = Expander PCF8574A
Device found at 80 =   (Not Programmed)
Device found at 82 =   (Not Programmed)
Device found at 84 =   (Not Programmed)
Device found at 86 =   (Not Programmed)
Device found at 88 =   (Not Programmed)
Device found at 8A =   (Not Programmed)
Device found at 8C =   (Not Programmed)
Device found at 8E =   (Not Programmed)
Device found at 90 =   (Not Programmed)
Device found at 92 =   (Not Programmed)
Device found at 94 =   (Not Programmed)
Device found at 96 =   (Not Programmed)
Device found at 98 =   (Not Programmed)
Device found at 9A =   (Not Programmed)
Device found at 9C =   (Not Programmed)
Device found at 9E =   (Not Programmed)
Device found at A0 = EEPROM 24LCxxx
Device found at A2 = EEPROM 24LCxxx
Device found at A4 = Wii Controller
Device found at A6 = Wii Motion Plus
Device found at A8 = EEPROM 24LCxxx
Device found at AA = EEPROM 24LCxxx
Device found at AC = EEPROM 24LCxxx
Device found at AE = EEPROM 24LCxxx
Device found at B0 =   (Not Programmed)
Device found at B2 =   (Not Programmed)
Device found at B4 =   (Not Programmed)
Device found at B6 =   (Not Programmed)
Device found at B8 =   (Not Programmed)
Device found at BA =   (Not Programmed)
Device found at BC =   (Not Programmed)
Device found at BE =   (Not Programmed)
Device found at C0 =   (Not Programmed)
Device found at C2 =   (Not Programmed)
Device found at C4 =   (Not Programmed)
Device found at C6 = AXE033 (Rev.Ed.)
Device found at C8 =   (Not Programmed)
Device found at CA =   (Not Programmed)
Device found at CC =   (Not Programmed)
Device found at CE =   (Not Programmed)
Device found at D0 = RTC (Maxim)
Device found at D2 =   (Not Programmed)
Device found at D4 =   (Not Programmed)
Device found at D6 =   (Not Programmed)
Device found at D8 =   (Not Programmed)
Device found at DA =   (Not Programmed)
Device found at DC =   (Not Programmed)
Device found at DE = RTC (MCP7940)
Device found at E0 =   (Not Programmed)
Device found at E2 =   (Not Programmed)
Device found at E4 =   (Not Programmed)
Device found at E6 =   (Not Programmed)
Device found at E6 =   (Not Programmed)
Device found at 36 =   (Not Programmed)
Device found at EC =   (Not Programmed)
Device found at EE =   (Not Programmed)
@stan74
I did the same yesterday to order also a VL53LOX to compare with the TOF10120 for range, accuracy, perpendicular reflecting surface dependency, interference surrounding light, etc. with info from BaldwinK.
 
Last edited:

AllyCat

Senior Member
Hi,

No, just connect the TOF10120 GND (Black) pin to GND (e.g. 08M2 Leg 8) and the 5v (Red) to supply/battery (e.g. 08M2 Leg 1) and link the SDA and SCL pins on TOF1020 to the same pins on the 08M2 (Legs 5 and 6 or c.3 and c.2) . The extra pins shown in the "ASCII Art" are only intended as a "Universal" interface to plug in normal 4-pin breakout modules, or to "protect" chips that have only 3.3 volt tolerance pins. It's mainly intended to use with the "larger" (14, 18 and 20) pin chips and difficult to use with an 08M2, because that doesn't have enough pins. Leg 7 has serial data so you can only use Leg 3 to switch either V+ or GND to the test module, also with changes to the program needed to select the pin(s).

Obviously the SerOut data on Leg 7 was switching (On and Off) the GND voltage to your TOF10120 and producing "garbage" on the I2C Data (SDA) line. The program should produce mainly "--" entries with just one (or a few) Slave addresses found (as shown in the example in post #2 of that thread).

Cheers, Alan
 

Haroen

Member
...pins on the 08M2 (Legs 5 and 6 or c.3 and c.2).
Legs 5 and 6 are C.2(sda) and C.1(scl). Why C.3?

Obviously the SerOut data on Leg 7 was switching (On and Off) the GND voltage to your TOF10120 and producing "garbage" on the I2C Data (SDA) line.
You're right, very logical!

I now connected my oscilloscope probes to the I2C (including the pullups) and get 0,43Vmax on SDA and 0,33Vmax on SCL.
Should be 5V in my case I think. Maybe the TOF10120 pins are damaged?

After posting I thought :unsure: "It can't be Sherlock Holmes":
When you have eliminated the impossible, whatever remains, however improbable, must be the truth!
Switch to another 08M2 PICAXE chip, voila...

Code:
SCL= 1  SDA= 2  V+= 0  GND=0

Vpsu = 4.93 Volts
Looking for Devices ...

   0  2  4  6  8  A  C  E      0  2  4  6  8  A  C  E
0 XX XX XX XX XX XX XX XX   1 -- -- -- -- -- -- -- --
2 -- -- -- -- -- -- -- --   3 -- -- -- -- -- -- -- --
4 -- -- -- -- -- -- -- --   5 -- -- -- -- -- -- -- --
6 -- -- -- -- -- -- -- --   7 -- -- -- -- -- -- -- --
8 -- -- -- -- -- -- -- --   9 -- -- -- -- -- -- -- --
A -- -- A4 -- -- -- -- --   B -- -- -- -- -- -- -- --
C -- -- -- -- -- -- -- --   D -- -- -- -- -- -- -- --
E -- -- -- -- -- -- -- --   F XX XX XX XX XX XX XX XX

Device found at A4 = Wii Controller
 
Last edited:

AllyCat

Senior Member
Hi,

Sorry a "typo" (of the brain) , yes c.2 and c.1.

If the "RS232" serial is working correctly, then the power supply must be OK. Therefore, it does look as if the I2C pins are damaged (but both would be surprising). So do check all the pin connections and voltages very carefully.

Cheers, Alan.
 

Haroen

Member
Yes, that chip I2C is bad.
The TOF10120 is on I2C now working correct on another 08M2.
It is reading the range in mm on b3 from 0 up to 255, then b2 gets 1 and b3 gets reset to 0 again.
Maximum distance is at b2=7, b3=208 gets to freeze at 1993mm.
Here is the code
Code:
#PICAXE 08M2
#no_data

INIT:
    hi2csetup i2cmaster, $A4, i2cslow, i2cbyte

Main:
    hi2cout (0)
    hi2cin (b2,b3)
    w2=255*b2+b3
    Debug
Goto Main
I could not have done this research so nice without the help of you all and the I2Cscanner of AllyCat(Alan) and PhilHornby!
THANKS!

I defenitly will make a dedicated I2Cscanner with pcb as a tool.
I have 5 questions though...
1) What is the essention of the extra 100K SerialIn pulldown resistor besides the already 10K+22K=32K in the PICAXE download circuit?
I tested it without the 100K and it worked fine.
2) This will also work on an (old) 08M?
AllyCat mentioned also Legs 5 and 6 besides the 08M2 C.2(sda) and C.1(scl).
3) For to I2Cscan a 3,3V device, could I just lower the supply voltage to avoid using the "larger" (14, 18 and 20) pin chips?
4) Is it better not to use 2x 4K7 I2C pullup resistors on the I2Cscanner board because the program can scan for it and even supply internal pullups?
But when the I2C device to be scanned already have pullup resistors then I will have 4K7 parallel values interfering with the I2C communication?
5) Could a I2C or Serial display make this project Stand-Alone?
 

AllyCat

Senior Member
H i,

Good that it's now working. Was it the 08M2 that was faulty? To answer your questions:

1) Some people assemble the 22k + 10k resistors on a "download" interface/module and then the PICaxe might not work when this circuit is removed. Thus the 100k is mainly a safety ("Belt and braces") feature. However, there are also a few occasions when the Serial (Programming) Input can be used as additional I/O, particularly if the pull-down resistor is greater than 32k. 100k is a good compromise, but even higher values should be satisfactory.

2) I don't believe that the 08M has any (on-chip) hardware, so it can't use the program in post #4. Possibly the program in #1 can be used, but some (hardware and software) modifications may be needed, for example with the testing of the supply rail and the pullup resistors.
Rev Ed / PICaxe prefers to use the term "Leg" to refer to the physical "Pin" numbers, i.e. Leg1 = V+ , Leg8 = GND for the 08M{2} , to avoid confusion with the Port.Pin numbers. The "older" PICaxe chips (particularly the 08M) did not use the "Port" letters and just referred to the "software" I/O numbers as "Pins" (Pin 1 = Leg 6 , etc.).

3) Yes, nearly all the PICaxes will work fine on 3.3 volts (or less), but some I2C Slaves might need nearer to 5 volts to operate correctly. The software/hardware with the "larger" PICaxes doesn't reduce the voltage to 3.3 volts, it simply "refuses" to supply power to the header pins if the supply voltage is too high. In principle that can be done even with an 08M2, Leg3 (c.4) could control either the V+ or GND to the "Device Under Test". If pullup resistors might be present then probably switching the GND would be better. For a more "advanced" tester (and a larger PICaxe) the PWM output (shared with SDA on the 08M2) could be used to reduce/control the voltage to the DUT (or of course an external regulator enabled).

4) For a single I2C "Device Tester" then probably using the Internal Weak Pullups is the best idea (it can even report if external resistors are fitted on a "breakout" board). But for testing a "Complete Bus" with many I2C devices and/or longer cables, then the WPUs may not be sufficient (~30k). Generally, it is acceptable to have two, and maybe more, (4k7) pullup resistors in parallel on the bus.

5) Yes, certainly a RS232 serial LCD/OLED could be used (with a modified program) to make a stand-alone I2C tester (but many of the older/cheaper LCDs do need a 4.5 - 5.5 volts supply). In principle an I2C display could be used, but there might be "complications" in using the same bus for testing and display. I don't believe any PICaxes directly support two I2C buses, but any larger chip could use "software I2C" (as in post #1) for one or both of the buses.

Cheers, Alan.
 

Haroen

Member
Hi Alan, yes the 08M2 is still faulty.

Response to your answers, for making a dedicated standalone I2Cscanner:
1) OK, that makes sense. I suggest to leave the 100K resistor in place altough there will be an onboard download circuit with the 10K+22K.

2) I agree, in the schematic I will advise only to use the 08M2.
Thanks for correcting me on the (Port.)Pin 1 = Leg 6 issue.

3) a) For the supply power wouldn't an external voltage regulator with a manual selection push switch be an idea to switch from default 3,3V to 5V? This way the user should be convinced that the "Device Under Test" is NOT 3,3V but 5V.
b) By using just a 4pins header instead of the Universal 8pins header the code can be reduced by eliminating the part for "refusing" to supply power to the header pins if the supply voltage is too high.

4) Because it can even report if external resistors are fitted on a "breakout" board and the fact that when implementing whatever I2C device, we also want to know if pullups are present. Here also I suggest for a manual switch for external pullups.

5) a) May I suggest to than avoid an I2C display and go for a serial one capable of 3,3-5V.
b) I think of a multi-line (rows count) display and colums characters enough after splitting the ASCII table in two parts.
 
Last edited:

stan74

Senior Member
I never tried running a 28x2 at 3,3V but I've run a 18f25k22 at 3.3v and it's logic level drives 3.3v logic devices
if any use.
 

Haroen

Member
@stan74, Thanks that makes me wander to test the 08M2 I2C bus with this sensor (datasheet 3-5V) on 3,3V.
I tried and it worked!
This device especially needs enough voltage compared with let's say a timer-IC because it has to transmit and receive laser light over the maximum distance for correct values.
I don't know however if the maximum I2C wire length reduces when using less voltage?
This is important because in most applications the laser distance sensor will NOT be used near the picaxe pcb.
I tested it with 1,2m I2C wires and it worked.
I have later to test the I2Cscanner on all sorts of devices for proper working.
 
Last edited:

Haroen

Member
I was impressed by their work too and recently ordered a VL53LOX to compare with this TOF10120.
I think that the VL53LOX will win in size when desoldering the sensor only.
@stan74
I did the same yesterday to order also a VL53LOX to compare with the TOF10120 for range, accuracy, perpendicular reflecting surface dependency, interference surrounding light, etc. with info from BaldwinK.
 

stan74

Senior Member
The TOF10120 will arrive soon I hope.Seems it's got serial and i2c out..I hate data sheets.
The VL53LOX is different to say a hcsr04 as it has a narrow beam and seems ok with different coloured obstacles...even cloth/fabric.
I posted this before but shows nice results. The program was written in a different basic so it runs on avr but could be converted
to picaxe as I try to convert picaxe to another basic...sigh.
 

stan74

Senior Member
Maybe contact manufacturer for free sample smd.
It's only a small board and the chip is not anything I would mess with. I don't see the point of desoldering it and rewirirg??
 

Haroen

Member
Nice robot job.
I like it that the rangefinder robot VL53LOX once focused stays focused even while turning around like it's alive :)
It's also fast responding when detecting the obstacle. I can't wait to try it with your I2C for picaxe code.
I did this R&D but was not sure in what project to use.
I think in a small Closed-Loop linear actuators or a digital long linear potentiometer.
It surely opens possibilities.
 

stan74

Senior Member
Nice robot job.
I like it that the rangefinder robot VL53LOX once focused stays focused even while turning around like it's alive :)
It's also fast responding when detecting the obstacle. I can't wait to try it with your I2C for picaxe code.
I did this R&D but was not sure in what project to use.
I think in a small Closed-Loop linear actuators or a digital long linear potentiometer.
It surely opens possibilities.
The
It uses cheap geared stepper motors, as I wanted it slower than pwm dc geared motors and a h-bridge.
I takes a whole port to drive the motors but have used an i2c port expander to run the same motors via uln drivers.
Bangood item not arrived yet :(
"I like it that the rangefinder robot VL53LOX once focused stays focused even while turning around like it's alive :) "
I do all avoidance robots with a servo scanner like that. It sees something in range and turns away but turns the the servo
so it still sees the object and turns more and repeats a while until it's past the object.
It has to account/allow for the size of the robot.
The distance it sees an object is less for ahead than left or right as a flat wide area would then be seen.
I like "robots" but there's the actual hardware and kitchen is not a workshop!
I tried a GP2Y0A21YK0F Sharp IR Analog Distance Sensor ...and it's imho, useless.
Ultra sonic is ok but not precise sometimes.
These little "tof" laser rangefinders seem an interesting way to go. Aren't we spoilt for gadgets to play with...and get a headache? -:)
ok this is for a 328p but it's basic and converting basics not fun
;set up V53L0X
#define HI2C_DATA PORTC.5 ;sda portc.4 for nano portc.5 for uno
#define HI2C_CLOCK PORTC.4 ;scl portc.5 for nano portc.4 for uno
#define HI2C_BAUD_RATE 400
HI2CMode Master
;
;v53l0x software restart
HI2CStart
HI2CSend(0x52)
HI2CSend(0x89)
HI2CSend(0x01)
HI2CStop
wait 200 ms
;
do
your code
loop
;
sub getdistance
HI2CStart ;Sys V53L0X Range Start
HI2CSend(0x52)
HI2CSend(0x00)
HI2CSend(0x01)
HI2CStop

HI2CStart ;read distance
HI2CSend(0x52)
HI2CSend(0x1e)
HI2CReStart
HI2CSend(0x53) ;set the read flag
HI2CReceive(distance_hi)
HI2CReceive(distance_lo, NACK) ;read one byte and conclude
HI2CStop
end sub
 

stan74

Senior Member
The V53L0X code , if you look in the forum came from proton basic and arduino c and sorted to picaxe by guys on the forum then
that code being converted to great cow basic by their version of "Hippy",who was a picaxe user called anonymous or similar.
different basics are not the same...I can't do c+ but I bet it's the same between versions.
 

Haroen

Member
I like "robots" but there's the actual hardware and kitchen is not a workshop!
I agree, I often get questions if I could make this or that for them that first seems easy to do but once I start all sorts of problems arrises.
The trial and mostly error method works, but you know what they say: The harder the battle the sweeter the victory.
These little "tof" laser rangefinders seem an interesting way to go.
I don't expect much difference between the TOF10120 and the V53L0X laser rangefinders but at least we now have code for PICAXE, proton basic, arduino c and great cow basic. Could maybe the V53L0X PICAXE code be added to this PICAXE forum for easy access?
Aren't we spoilt for gadgets to play with...and get a headache? -:)
Yeah, but if I could have this 40 years ago when I build my LEGO-Technic Combat Vehicle tank with rotary canon on wire-remote to battle my brother with his Fisher-Technic tank, then I don't mind the headache!
The tank could then be instead of your avoidance servo scanner, a tracker servo scanner to fire at...:giggle:
 

stan74

Senior Member
Picaxe is great for robots but getting cheap interesting devices to work is not always easy. You search for info...and arduino seems to have it sorted
for you with an include file.
In picaxe it's up to Hippy and the forum to advise as converting c+ to basic is not impossible but if you could use c+ then you would be using
it in mplab for pics or arduino for avr.
I don't do c+ so use basic and get results. I still got my picaxe boards but it's so long and thank you for all the fish. (HitchHikersGuideToTheGalaxy)
Picaxe followers are very dedicated and loyal but like I won't learn c+ they won't try alternative basic.
The basic I use now doesn't use b1,b2 as variables
they are anynamevar as byte,word.long.$ and limit depends on ram.
picaxe variables are a limiting factor even though a 28x2 has 1.5k ram
With hippys help I got ssd1306 oled display to work in picaxe and that needs a 1k ram buffer.
but there's no include file for it..so I use basic with #include ssd1306 and then can do stuff.
gcb version
 
Last edited:

stan74

Senior Member
I asked on another forum for a picaxe to gcb converter but no luck.
If it could work in reverse , gcb to picaxe then the device includes would be useful hardware additions and easier to convert to picaxe than c+ libs.
 

Haroen

Member
I use PICAXE frequently for R&D low speed project processes and this forum is most helpfull for implementing code to learn and understand.
They are patient and the software and hardware tools are great to get started even with China sensors and actuators the PICAXE can still control that.
For Microchips I use MP-LAB.
I've downloaded great cow basic to try the V53L0X code and Arduino.

SourceCode conversion I learned this from AllyCat (Alan ) in this thread when I asked...
Is it possible to extract the PICAXE code needed from the working Arduino code?
Possibly for very "simple" code, however I won't do it. But generally the issues are with Hardware compatibility, or information buried deep in a "Library", rather than the raw code.
I struggle with the same issues you're having.

The ssd1306 oled display(has sda, scl for I2C but maybe serial variant excist) could be the solution for the I2Cscanner of AllyCat(Alan) and @PhilHornby mentioned in this thread on post #20-22:
I could not have done this research so nice without the help of you all and the I2Cscanner of AllyCat(Alan) and @PhilHornby!
...
5) Could a I2C or Serial display make this project Stand-Alone?
5) Yes, certainly a RS232 serial LCD/OLED could be used (with a modified program) to make a stand-alone I2C tester (but many of the older/cheaper LCDs do need a 4.5 - 5.5 volts supply). In principle an I2C display could be used, but there might be "complications" in using the same bus for testing and display. I don't believe any PICaxes directly support two I2C buses, but any larger chip could use "software I2C" (as in post #1) for one or both of the buses.
5) a) May I suggest to than avoid an I2C display and go for a serial one capable of 3,3-5V.
b) I think of a multi-line (rows count) display and colums characters enough after splitting the ASCII table in two parts.
 

AllyCat

Senior Member
Hi,
5) b) I think of a multi-line (rows count) display and colums characters enough after splitting the ASCII table in two parts.
I'm not sure what you mean by "ASCII Table" but if you mean the "Tabular" (Table) display of the Slave Addresses of the program, then I considered that a "Gimmick" (I don't know if that will translate) , which I nearly removed. IMHO all that is needed for a simple custom "tester" is to display a Slave Address (or two), a few "Error" Codes (or numbers) and perhaps a "Name" / Type Number of the Slave. There are only 112 available Slave Addresses, so (as we have already found), some are allocated to multiple (different) devices, particularly since I2C Memories often use 8 adjacent addresses.

I didn't respond to your earlier comments, but personally, for a "User Interface", I believe in the "Keep It SimpleS" philosophy. I would NOT add any (toggle) switches, but just use the PICaxe to change any "configuration" options, e.g the (weak) pull-up resistors on/off and supply voltage/pins, etc.). Maybe just a (few) low-cost pushbutton(s) input, which can be easily "debounced" by the software, if necessary. The "header" in the "ASCII Art" of that program was mainly intended to show how 6 contacts along the edge of a Solderless Breadboard could be used (with one of the larger PICaxes) to test many configurations of Breakout board.

For a dedicated hardware "tester" one might include a (e.g. 14-pin) "Zero Insertion Force" (ZIF) IC socket, arranged with most permutations of the 4 pins, but the KISS solution is just 4 pins and a short "Dupont" M/F ribbon cable, which could accept ANY sequence and spacing of header pins. Note that since I2C is basically an "Idle High" system, the Vcc of the DUT (Device Under Test) could be connected (unconditionally) to the supply rail and just the Earth (e.g. from pin c.4 of an 08M2) used to protect/switch/modulate the Earth connection to a lower voltage (e.g. 3.3v) DUT.

5) ... The ssd1306 oled display(has sda, scl for I2C but maybe serial variant exist) could be the solution for the I2Cscanner of AllyCat(Alan) and @PhilHornby mentioned in this thread on post #20-22 :
Yes, I considered the SSD1306 and one of my (many) projects "On the Back Burner" is an 08M2/SSD1306 emulation of the AXE133/4 (maybe even towards the AXE033). The bit-mapped display maps quite well to a "1602" (8x16 pixels ASCII font) or "2004" (6 pixels wide characters), using "Double Height" characters for the 128 x 64 pix version. Most of the "font" coding is already done and documented HERE , but I still need to finalise the HSERIN input code, to support the much more intensive (complex) and slower (bit-mapped) display driver.

The problem with an I2C display (on a single bus) is that it can't report any of the "Bus Faults", because the bus must be working correctly. However, for this project, it would be possible to use the "Bit Banged" I2C code from post #1 of my Code Snippet thread on "different" pins, leaving the (embedded hardware) I2C bus to drive the SSD1306 as quickly as required. A "larger" PICaxe would be better, but it might just fit onto an 08M2: Pin C.4 could be the SDA(2) line. In most cases the SCL doesn't need to have a Tri-State capability (which is only required for "Clock-Stretching" devices) so the C.0 (Serout) pin probably could be used for SCL(2). Pin C.0 does actually have a Weak Pullup and Tri-State capability, but that's definitely straying away from the KISS principle. ;)

Cheers, Alan.
 

stan74

Senior Member
This is the i2c hardware address finder I use. Yeah,not picaxe. But is it easy to transfer?
I should add this is for mega386p and uses the i2c hardware ports.
You want to see the pic 18f25k42 version where every pin used has to be defined. It's the way with newer microchip 8bit pics.
They don't have default values. I don't like them and bought a dev board from microchip.Works but defining pins even with a tool is a pain. You end up looking at data sheets.
rem ' or ; is a rem statement

dim deviceID as byte
' Define I2C settings
#define HI2C_BAUD_RATE 400
#define HI2C_DATA PORTC.4
#define HI2C_CLOCK PORTC.5
'I2C pins need to be input for SSP module when used on Microchip PIC device
; Dir HI2C_DATA in
; Dir HI2C_CLOCK in

'MASTER MODE
HI2CMode Master

#define USART_BAUD_RATE 9600
#define USART_TX_BLOCKING
; Dir PORTc.6 Out
#define USART_DELAY 10 ms

do
HSerPrintCRLF 2
HSerPrint "Hardware I2C Discover using the "
HSerPrint CHipNameStr
HSerPrintCRLF 2

for deviceID = 0 to 255
HI2CStart
HI2CSend ( deviceID )

if HI2CAckPollState = false then

if (( deviceID & 1 ) = 0 ) then
HSerPrint "W"
else
HSerPrint "R"
end if
HSerSend 9
HSerPrint "ID: 0x"
HSerPrint hex(deviceID)
HSerSend 9
HSerPrint "(d)"+str(deviceID)
HSerPrintCRLF

HI2CSend ( 0 )
HI2CSend ( 0 )
end if

HI2CStop
next
HSerPrintCRLF
HSerPrint "End of Device Search"
HSerPrintCRLF 2
loop
 
Last edited:

stan74

Senior Member
I use PICAXE frequently for R&D low speed project processes and this forum is most helpfull for implementing code to learn and understand.
They are patient and the software and hardware tools are great to get started even with China sensors and actuators the PICAXE can still control that.
For Microchips I use MP-LAB.
I've downloaded great cow basic to try the V53L0X code and Arduino.

SourceCode conversion I learned this from AllyCat (Alan ) in this thread when I asked...


I struggle with the same issues you're having.

The ssd1306 oled display(has sda, scl for I2C but maybe serial variant excist) could be the solution for the I2Cscanner of AllyCat(Alan) and @PhilHornby mentioned in this thread on post #20-22:
You say "I've downloaded great cow basic to try the V53L0X code and Arduino."
I didn't want to make people download another basic rather try converting code...usually from c+ as it sorts devices faster than other systems.
I guess rpi would come second place.
The rest of us have to search for info for a device that seems new but has been around for years.You find examples on github dated years ago.
Anyway join the gcb forum and say what you need and there's many picaxe users to help.
It will be odd at first but when I first used it it was with an arduino uno and because it's usb plug and play it just worked and the same usb can serial print to the terminal in the ide.
Much easier than using a pic and pickit 2 or 3 and then a ttl to usb converter to use a terminal.
Gcb now supports the Logic Green LGT328p that runs at 32Mhz,that's twice as fast as a atmega328p and remember 16Mhz 328p is same speed as 64MHz pic.
It is very fast
 
Top