TXT Controller and I2C speed

[fotoopa]

I have done many tests again with the I2C bus to connect the TXT to my own hardware. What your hardware is doesn't matter, may be an existing microprocessor module or your own preference for hardware. The TXT is independent of this. My projects are always with a permanent power supply I don't use the TXT display because it is far too small. I'm 75 years old and my eyes can't see those small pixels anymore. That's why I always use a UDH screen. The connection of the PC and the TXT can be done with both USB and wlan at your choice. As hardware I use my FPGA controller which was designed for the ball track. Now I'm going to use it further for new projects.

Now the speed test of the TXT Controller via I2C readout.
All results are displayed on the PC monitor. Images are optimal for a UHD screen 3940x2160 pixels. 32 bytes of data are read out. If you leave the device open, all 32 bytes will be read without interruption. The total time for this is 770 usec. The test program has been written to investigate how fast new data can be read from the I2C bus. At the same time, all results are displayed on the screen. The TXT controller must convert all values to the display format and display them.

As a test I use:
16 FT Motors with speed setting, direction and enable visualization. 4 of these motors have an encoder counter whose value is displayed on the screen (is not a restriction and can be further expanded). The speed is adjustable between 0 and 100 for each motor. This speed is also shown on the display. There is provision for 16 servo motors (32 are available in the hardware) in which the position status is read out, left or right. This is also displayed on the screen. Finally, there are 16 inputs that are also displayed (they may be extended to any number).

Note that you can also switch between 8 and 16 bit data with an open device. If the slave is able to answer this number correctly, everything will be processed as a series without waiting loops. This greatly increases the transfer speed of the 32 bytes. The test indicates that there are 438 burst reads per second. The PC display shows the correct results during the tests.
A few pictures:

Flickr link: https://www.flickr.com/photos/fotoopa_hs/41950724482

The timing of an optimal burst read:

Flickr link: https://www.flickr.com/photos/fotoopa_hs/28123464158

Test program:

Flickr link: https://www.flickr.com/photos/fotoopa_hs/28123465048


Flickr : https://www.flickr.com/photos/fotoopa_hs/41994869511

If you want to work with a closed devive now, there will always be an interval between reading the separate data. This makes the reading speed considerably slower. We now obtain an average of 28 refresch cycles instead of 438 / sec. You see the hardware of the I2C device determines your result.
Here are the two results:

Flickr : https://www.flickr.com/photos/fotoopa_hs/41994869821

The I2C slave driver I wrote for my FPGA can process both single and multiple bytes without additional clock delays. It automatically detects if the TXT wants more data at once. It also supports 8 and 16 bits. That's why 32 bytes of read with a mixed data length of 8 and 16 bits takes only 770 usec ( (32 byte data + 2x address) * 9 bit = 765 usec @ 400 KHz) with an open I2C device except the last access.

The display is updated less quickly than reading the I2C. Nevertheless, this is going quite fast. I tested the 4 encoder counters which increases 15 counts/sec and this ensures a smooth reading on the PC. However, I do not yet know very well how to have proper control over this.

Frans.

[steffalk]

Hello fotoopa,

what a fine analysis you have done! Wouldn't you like to describe that in more detail in an ft:pedia issue?

Best Regards,
Stefan

[fotoopa]

what a fine analysis you have done! Wouldn't you like to describe that in more detail in an ft:pedia issue?

Dear Steffalk,
I am not such a good writer. I would, however, like to communicate new tests and programmes on a regular basis. I am currently working on an I2C version with the Robo TX. All basic basic functions are in the own hardware via I2C. These are functions such as moving the motor xx to pos xx. Or move the motor xx to the zero point. I added a rotary encoder to the robot on the X, Y and Z axes. The original encoder motors are dummy encoders, they do not even have a direction detection, only pulses. They then try to correct this by means of software. In the longer term, this is totally incorrect. A Rotary encoder should never miss a single impulse, even if you're working a full day without going again to the zero-point for calibration. The encoders I use are low-cost mechanical versions with 96 pulses per revolution and are simply mounted on the end of each axis.
See: http://www.electroshopdendermonde.be/in ... rot-potdi/

I can already send commands to my own hardware via the I2C of the TXT controller. Also reading the motor position works perfectly. I am now working on a small project in which an 8x8 matrix. There are 64 holes where a steel ball can be inserted by the robot. As input of the matrix you can enter a certain letter. The robot will then apply the dots, "Steel balls" itself. If you want to form a different letter, the robot will look at the difference in the necessary dots. Dots that are not used can then be taken to the new necessary dots or back to the stock box. I still have to find an optimal algorithm to make the shortest movements for the new letter.
I have also added a mini reflection sensor. At the powerup or a restart, the robot does not know where there are balls in the dots. He first makes a scan and when he finds a "Steel ball he takes it out first. In this way he can start from an empty maxtrix.
Instead of forming letters, I also provide an input for making a creative drawing myself. After a start command, the robot then has to copy the drawing using the steel balls. Such a program must work through a large PC screen. That's why I always use my 32 inch UHD monitor 3940x2160 pixels.

The matrix is drilled the next few days. Then I can start with the real tests. So more on this later.

Frans.

[fotoopa]

The mechanical update of the robo TX unit has been accomplished. This setup will be further used for different speed tests of the TXT Controller. The 3-axis counters are supported in the external hardware. On the TXT controller, only the I2C connection is used for the hardware. The software for the TXT Controller is now being rewritten. The whole thing must work online with the PC and the UHD screen. This way I have a good overview with very high resolution and I can use the mouse of the PC to control everything. Here are some pictures of the new setup of the robot:


Flickr link: https://www.flickr.com/photos/fotoopa_hs/40325159240



Flickr link: https://www.flickr.com/photos/fotoopa_hs/40325157980


Flickr link: https://www.flickr.com/photos/fotoopa_hs/42085895652


Flickr link: https://www.flickr.com/photos/fotoopa_hs/42085894392

Notice how I carried out the new wiring of the motors, switches and detector. I use flexible twisted wire from a thick cable of 16x2 wires for this purpose. So you can process all the wires in a flexible string. Note that I have replaced the original fork system with a magnetic holder. This way I can pick up the steel balls of 12.7mm and place them in a matrix with 8x8 holes. By inserting the steel balls into the matrix, you can create different figures. The sensor located next to the magnetic head is used to scan the matrix during powerup. After an emergency stop or powerup, you will otherwise no longer know where steel balls are already in the matrix. This still requires a lot of software for the TXT Controller. The external hardware only executes the basic commands for the motors and processes the encoders and switches signals. I am now going to write a small program to operate the motors from the PC. The motors can already be controlled manually from the external hardware. Via the TXT controller, the X, Y and Z positions of the motors are already displayed on the PC.

The encoders, end switches and detector are brought together in a small black box. This can be seen in the first picture. This input box with 24 inputs is connected to the external hardware via SPI (@500KHz). The reflection sensor is refreshed every 4 msec.

Small update:
The encoders have 96 pulses per revolution. The worm has a module of 1.5mm. 1 tour has 1.5x3.14mm = 4.71mm. 1 pulse on the decoder : 4.71/96 = 0.05mm. 1 FT raster = 15mm or 305.6 pulses --> 306 pulse on the encoder!. I am going to make a matrix with a grid of 16x16mm or 326 pulses per grid. This gives me an enormous good resolution even if the motor runs through some pulses. Errors are not cumulative. The encoders always maintain the correct position even when you rotate the shaft manually. The grid positions are 326 ... 652 ... 978 ... 1304 etc. Both horizontal and vertical. For the time being I see a maximum difference of 4 pulses when stopping the motor on the X axis. On the other axes this is only 1 pulse because the speed is slower. I do not therefore need to correct this error.


New speed data will follow later.
Frans.

[fotoopa]

Update of the original ROBO TX robot, now controlled by external hardware and software on the TXT Controller. The 3 motors, X, Y and Z axes already work manually. You can move the axes with mouse click on the PC screen. The external hardware is connected over an I2C bus. The basic functions are performed on the external hardware. The executive program is on the TXT Controller.

The robot must control a matrix wall with 64 holes. The pattern for filling is taken from a charactor rom. On the PC screen you can select the desired character. The character rom is located in the external hardware. Several types of rom can be mounted. Several drawings can be stored in this way. The external hardware transmits the pattern to the TXT controller via the I2C bus. This is 8 bytes, or 64 bits for a complete pattern. When all the steel balls have been placed in a wall by the robot, you get the same figure as on the screen. For the automatic placement, further software is currently being written on the TXT Controller. New Rotary encoders ensure a very accurate position of all axes. 1 pulse at the encoder corresponds to 0.05mm or 20 pulses/mm for the axis displacement. There are no cumulative errors because the encoders also contain the direction and always count correctly even if you manually rotate the axis.

The TXT Controller is very easy to program.
Screen dump van the running TXT software:



Link to the HD version: https://www.flickr.com/photos/fotoopa_hs/27323125217
More information about the program and a short video will follow later. First I have to drill the wall which has 64 holes.

Frans.

[fotoopa]

The software for the robot is ready for testing. Here you see a screen dump of the run mode.



Link to the HD picture: https://www.flickr.com/photos/fotoopa_hs/28473719448

According to the lightening dots, steel balls are placed in a wall matrix by the robot. Information during positioning can be followed on the screen. The encorders are read out in real time and placed on the screen. Motion directions are also displayed. A counter has been added to indicate how many refresch bursts occur per second of the I2C connection. This varies around 200. This indicates that the TXT Controller is very fast to readout in realtime the data information ( burst of 24 byte ) .

Here the program works in run mode. The steel balls are brought from the input to the wall according to a selected pattern. During run mode you can see which dot is processed, indicated by the blue horizontal and vertical points in the matrix. This will become even clearer later on on a video. The status of the end switches of the 3 axes is also visible in real time.

The pattern used here is the character 58 from the character rom. This value can also be followed on the PC screen. At the beginning of next week I can drill the holes for the wall. There will be 2 more sensors placed to see if there is a steel ball on the robot arm.

I'm very surprised how fast the TXT Controller can process the data. Of the original TXT controller I only use the I2C connection. The external hardware only has very basic commands to process. Orders such as position the axis, gives the status of the end schwith, and read out the encoder position. All other data is processed by the TXT Controller program. A lot of screen LEDs are used. The matrix itself already contains 64+16 LEDs. Extremely beautiful on a UHD screen! Also the operation with a simple mouse click is super comfortable. I will also make the entire program available, but you really have to support the necessary external functions to work online. Still, you can already investigate well how I wrote the program. The file size of the .rpp is now about 2 Mbyte.
So, within a short time more information will follow.

Frans.

[fotoopa]

As planned I finished today the matrix wall 8 x 8.

Link full size image: https://www.flickr.com/photos/fotoopa_hs/40582655670

Drilling the matrix holes 8 x 8 on the milling machine. You have to pay a lot of attention to drill all the holes according to the drawing. The holes have been drilled 3 times. First, pre-drill all the holes with 12mm, Then, with a 14 mm milling cutter, measure neatly. In order to prevent the steel balls from falling out of the opening on their own, another drill has been drilled but now 1 mm has been shifted downwards but 3 mm less depth. The holes are on a 16 mm grid. The material used for the wall is MDF board of 12mm.

Here is an overview of the wall mounted on the robot:

Link full size image: https://www.flickr.com/photos/fotoopa_hs/42390831761

The matrix is filled by a pattern that you choose via the robo TXT software on the PC screen. On the left there is the input for the steel balls and slightly upwards, the ouput for the outlet. There are also 2 reflection sensors added to allow control of whether a steel ball is actually present. On the arm of the robot there is another sensor to scan the filled matrix. This is necessary if the matrix is to be emptied automatically. After powerup it is possible to first perform a scan to empty the matrix.

Now I have to update all the position values for the software so that everything can run perfectly automatically. Then I can make a short video. I'm also going to have some extra programming options. Now the drawing comes from the selection of the charactor generator rom. I will add a drawing mode so that you can immediately create your own patterns and let the robot execute them.

Frans.

[fotoopa]

Update of the software for controlling the Robo TX module with external hardware and connection via I2C and the TXT Controller. An additional measurement for the refresch timing of the main program has been added. It is also now possible to make a drawing yourself. Soon another control button will be added to choose between a figure of the character rom or of your own drawing. All positions for placing the steel balls have meanwhile been filled in by calculation. During the tests I saw that the vertical movement is not perfectly perpendicular to the base. The guides of the Fischertechnik blocks are too narrow to do this properly. I have then added an extra correction factor to the calculation, depending on the height of the vertical carriage. This works perfectly so that the position of the steel balls always remains perfectly central with respect to the opening in the wall. The speed during standby, i.e. no command execution, is for the I2C connection 101 and for the main program 51 refresh cycles/sec. That is very good! During run mode, the main is no longer loaded and then the I2C connection has about 200 refresh cycles/sec. All data updates gets very fast. Meanwhile, the screen is updated perfectly and all parameters such as encoder positions and all status values are displayed in perfect order. The TXT Controller does an excellent job with a very nice resolution on the UHD screen.

Run mode also works. I still have to manually perform the input of the steel balls but all the movements according to the matrix rom are already correct. When I give him the steel balls he places them in the right place in the wall. Soon this supply will also be realised automatically.

Here is a new picture of the current version:

The full hd image on Flickr: https://www.flickr.com/photos/fotoopa_hs/42385086322

Frans.

[PHabermehl]

Absolutely impressive!

[fotoopa]

Absolutely impressive!

Thanks!
Now that I've started to understand programming with the Robo software, the development of my own applications is much faster. This morning I added the manual drawing to use in the run mode. The drawing is taken over in the upper matrix, the rest of the execution is therefore the same as the data of the charactor rom. Now I still have to make a safe input for the steel balls. I'm going to test this with an extra XS motor. Up to 64 steel balls must be available. If you put them in a row the pressure on the last ball could be too great. The program is already 2.6 Mb. As soon as the supply of steel balls works I will make the program available on the forum. Without the external hardware, you can't really run the program, but you can still view the different parts. and how I have programmed certain routines. I also regularly look at other programs to discover certain techniques that were used.

I think the method how to program the TXT Controller is very similar to the methods with an FPGA. Especially logical thinking and the logical building blocks are the most important elements. A small disadvantage is how the TXT Controller handles subroutines and multitasking is not always clear. That's why I regularly take measurements via the software, but also via the hardware and a scope. I remain a true supporter of combining the TXT controller with your own external hardware that is connected via an I2C connection. My applications do not need a battery and are connected to the power supply, so rather a fixed setup. I can make good use of a UHD screen and with the mouse control. For example, the drawing matrix already has 64 LEDs and 64 push buttons. You can never place this on a small screen. At the age of 75 I have a great hobby with this!

Frans.

[PHabermehl]

At the age of 75 I have a great hobby with this!

Frans.

And it's fun following up with your progress at any age! I eagerly hope that I will be able to do things like this when I'm retired (twenty years from now, maybe...)

Kind regards
Peter

[fotoopa]

The additional XS motor has been added to the Robo TX to feed in the steel balls. I have taken some detail photos:

Original HD: https: //www.flickr.com/photos/fotoopa_hs/42425629332


Original HD: https://www.flickr.com/photos/fotoopa_hs/28603830098


Original HD: https://www.flickr.com/photos/fotoopa_hs/42475967511


Original HD: https: https://www.flickr.com/photos/fotoopa_hs/42475967951


Original HD: https://www.flickr.com/photos/fotoopa_hs/42475968421

Now the entire program also works in run mode. In this way, the supply of steel balls works very simply and reliably. In the TXT controller I only had to add 1 extra command. This command is executed in the external hardware: place 1 extra ball on the input.
Very simple and, above all, quick to implement.

Frans.

[fotoopa]

In order to provide the input with the steel balls, a transport of up to 64 balls had to be provided. Not so simple because the balls don't roll forward easily when they are lying still. However, I have provided a control sensor when picking up the ball. If there was no supply, I can intervene. A warning message will appear on the control monitor.
Now I still have to create a program segment to automatically empty the matrix. The automatic filling of the matrix now works perfectly both with a pattern supplied from the charactor rom or from your own made drawing. File size of the program is now 3.3 Mb.
Here are a few new images:

Full HD picture: https://www.flickr.com/photos/fotoopa_hs/40687626920


Full HD picture: https://www.flickr.com/photos/fotoopa_hs/41773328814


Full HD picture: https://www.flickr.com/photos/fotoopa_hs/41773330114


Full HD picture: https://www.flickr.com/photos/fotoopa_hs/40687627680

The complete programme still needs to be fine-tuned here and there. The emergency stop must also be fully tested. The project is already well advanced. It's time to think about another module.

Frans.

[fotoopa]

A small update:
Because of problems with my mechanical rotary encoders, I started working on a design to make it myself. The purchased encoders were perfect until an axial pressure came up. As a result, there were internal deformations which resulted in malfunctioning. That's why I started my own design to make the rotary encoders myself. They can absorb pressure axially as well as radially without errors. I've just made a prototype to determine the dimensions. This does not always go perfectly from the first test. The intention is that the whole thing remains rather small. The first test was with 3mm neodymium magnets on a diameter of 19mm. But this didn't work out well because the magnetic field was too strong. I then made new tests with magnets of 2mm. This test was already much better. Finally, the magnets will be in a circle of 25 mm. The outside diameter will then be 30 mm and the material used will be delrin (Pom). I have these round axles on order and they will arrive this week. Meanwhile I can create the PCB layout for the detectors. The detectors are located at a distance of 10.16mm between each other. This way I get a dual encoder signal at 90 degrees shifted. There are 12 magnets, this gives me 48 pulses per revolution. With a Fischertechnik wormscrew, the resolution is 0.1mm. The detectors are the AH3144 and are insensitive to ambient light, have a built-in hysteresis and operate between 5 and 24V with open collector output. They are therefore also suitable for direct connection to the TXT controller with 9V. And yes I know you can buy other encoders but making them yourself is always a bit more fun. It was also intended that the encoders would be placed on the axles and not in the motor. This excludes a number of slip errors.

A picture of the messy measurement setup:


HD version: https://www.flickr.com/photos/fotoopa_hs/42038650284

Because of these problems I have some delay with the project. Once the encoders are ready, it will work perfectly!

Frans.

[fotoopa]

Today the material arrived (delrin) to make the rotary encoders. After previous tests, I decided to use only 10 magnets per encoder. If you are using a worm M1.5 this is still 0.12mm/pulse displacement. In this way, the maximum encoder diameter is limited to 30 mm, which is standard with Fischertechnik. With these 10 magnets I obtain 40 pulses per revolution via quadrature detection. The already made dual hall detectors work perfectly on this. The signals are adjustable to a 50/50 ratio with a shift of 90 degrees. This is necessary with these encoders. The 10 magnets provide 40 pulses per revolution, which is sufficient for most applications. The magnets have a diameter of only 2mm and are placed on a radius of 25mm. This 25mm diameter gives a perfect ratio of 50% for the encoder signals. The center distance of the hall detectors is 10.16 mm. By regulating them horizontally and vertically you obtain a perfect signal.
Some images:


HD version: https://www.flickr.com/photos/fotoopa_hs/42880074341


HD version: https://www.flickr.com/photos/fotoopa_hs/42831944602


HD version: https://www.flickr.com/photos/fotoopa_hs/42880073561



I have created a new SPI 24 digital high-speed input.
SPI clock: 500 KHz
Refresch time scan min : 52 usec
Inputs: 24, 3K3 pullups, 12 inputs with 10nF filter.
Input Levels: TTL or 5V
Power to input devices: 5V


HD version: https://www.flickr.com/photos/fotoopa_hs/28979433618


HD version: https://www.flickr.com/photos/fotoopa_hs/27983459257

The diagram drawn for a single-sided printout:

HD version: https://www.flickr.com/photos/fotoopa_hs/42780200522

The layout for this SPI interface together with the hall detectors:

HD version: https://www.flickr.com/photos/fotoopa_hs/42780201072

Result after etching:

HD version: https://www.flickr.com/photos/fotoopa_hs/28957610528

The software in the external hardware has also been modified. Soon I will be able to start up everything to equip the TX robot with my own rotary encorders.

Frans.

[fotoopa]

The assembly of the SPI 24 bit input box is finished. The box is connected to the external hardware and tested. I now have 24 additional digital inputs for my Fischertechnik projects. The status of these 24 inputs is also shown on the LCD display of the external controller. They can also be read via the I2C of the TXT Controller. Scanning time can be up to a minimum of 52 usec for the 24 inputs. This corresponds to a maximum of 9.5 KHz signal at each input pin. These additional inputs are mainly intended for rotary encoders. This is almost 10x higher than the 4 counter inputs on the TXT Controller. Up to 12 full rotary encoders can be processed in this way.

Here is a picture of the small interface box:

Bigger version: https://www.flickr.com/photos/fotoopa_hs/28031870387

Input level is 5V or TTL, there is an internal pullup from 3k3 to +5V present. You can also connect regular switches to it.

Frans.

[fotoopa]

I made an extra adjustment for the rotary encoders. The aim is to enable an auto calibration in which the position of the robot retains an absolute value. To do this, a one-time calibration procedure must be applied at start-up. An extra switch is needed on the robot arm. It is located in a unique place and may only give a pulse over a maximum of 1 rotation. This switch together with the home signal of the encoder and the information of both encoder signals A and B form a unique place determination. The direction of the robot is therefore also included in this positioning. Each time the robot moves over this unique place and in the right direction a reference calibration is automatically loaded.
The test setup:

HD version: https://www.flickr.com/photos/fotoopa_hs/29048555088

Measurement signals scope:

HD version: https://www.flickr.com/photos/fotoopa_hs/28052136517

Note my scope has only 2 channels. I cannot display all 3 signals at the same time. I chose the encoder A signal together with the encoder home pulse. This way you can see a complete rotation of the encoder. From the quadrature signal of A and B you can make 40 pulses per turn. Here you see that the XM motor needs 86 msec to make 1 revolution at the max speed. This corresponds to 698 rpm, runs idle.

Frans.

[fotoopa]

The new quadrature encoders are now also mounted on the x-axis of the robot. I use an additional reference detector for this. Together with the home signal and the direction on the encoder, I obtain an absolute position. Each time the robot moves in the right direction over the switch , and at the home signal, the reference value is loaded into the counter. This automatically maintains the correct value at all times. This reference position is sent by the TXT Controller during powerup. The external hardware already contains a default powerup value if the TXT controller does not control it.
Some pictures:

HD version: https://www.flickr.com/photos/fotoopa_hs/42978682511


HD version: https://www.flickr.com/photos/fotoopa_hs/42260225154


HD version: https://www.flickr.com/photos/fotoopa_hs/42260224704


HD version: https://www.flickr.com/photos/fotoopa_hs/42260225464

The logic analyser is now also connected. This allows me to see more signals at the same time. The reference switch must be adjusted in such a way that no signal is generated for more than 1 revolution. Together with the home signal on the quadrature encoder you get a unique position value to load into the counter. You can now read all the timings on the LA. This makes it possible to see the time of a complete rotation of the axis. So you can directly determine the number of rpm of the motor. This function is now fully tested and works perfectly.


HD version: https://www.flickr.com/photos/fotoopa_hs/42077186605

There is still a problem to treat and that is the backlash on the robot shaft. With the current installation by Fischertechnik, this value is approximately 0.7mm. I am going to resolve this by always moving in the same direction. If I need a negative direction, then I will first go a little further and then return to the right direction. This function can also be performed automatically in the external hardware. So there would be no extra load for the TXT Controller. I am now going to add this function.

Frans.

[fotoopa]

The project with the robot for the matrix 8x8 has been completed. The last difficulties have been solved, like the backlash and the slow positioning at the end. I have built these functions into the external hardware so that the TXT controller only has to give the command "go to the position". It is all handled by the I2C bus of the TXT Controller. It couldn't be easier.
The TXT controller did not use any other inputs or outputs, only the I2C bus. The TXT Controller is great for displaying everything on the PC screen in UHD real time. All position values and status are displayed very quickly. Actually even faster than on the viedeo because the video capture software provides a large load to record HD images together with the Robo TXT Controller.Even in these circumstances, things are still going quite well.

I have uploaded the Robo program but apparently it is not yet available. I don't know if there are any problems. You need to have the right I2C registers to run the program in online mode. But without this correct connection, you can still see the entire program how I wrote it. It is not small, about 3.7 Mb. You can see the layout on the PC screen. This layout can also be seen on a video made in full HD:

https://youtu.be/7SJqeSHPiRQ

The video is edited with Pinnacle studio 19 Ultimate.

Frans.

[fotoopa]

The program for the matrix 8x8 robot has finally been put online on the download page, I had already done this 10 days ago, even twice, but because of this it is now double placed on the download page. If a moderator can take one back it would be nice!

Today I expect the delivery of different I2C modules from Adafruit such as:
- Adafruit I2C Non-volatile FRAM breakout - 256Kbit / 32Kbyte
- RGB Colour Sensor with IR filter and White LED - TCS34725
- 4-channel I2C-safe Bi-direction Logic level convertor BSS138
- VCNL4000 proximity / Light sensor
- TSL2561 digital luminosity / lux / light sensor breakout
For the color sensor I have already found the description in the ftpedia-2016-1.pdf and the program thanks to Dirk Fox.

I'm now going to test and measure these I2C modules and add the color sensor to my robot. I will find an application for this, I would like to sort colored pearls (D10xL10mm). I still have to make a small interface pcb for 5V and 3V3 from the 9V of the TXT controller, along with connections for the additional I2C modules.
Results will follow in the coming weeks.

Update: 2018-07-10
As planned, they delivered the I2C modules today! I now have some work to connect them and test them on the Fischertechnik TXT Controller.


HD version: https://www.flickr.com/photos/fotoopa_hs/43268790182

Frans.