fotoopa Posted January 9, 2022 Posted January 9, 2022 Since there are no extension flat cables available, you have to make them yourself. I did this by cutting a pressure sensor cable to get the Hub connector. With a Raspbery PI Hat I cut the other side of the connector free and soldered an extension to it. Now I can measure all signals with the Pico scope. This way I can see the RS232 values, measure the protocol and possibly connect another type of sensor or interface. Later I hope to give more details about this. A few pictures on Flickr: DSC07753-meet-opstelling by Frans, on Flickr DSC07744-motor-pwm by Frans, on Flickr DSC07711 by Frans, on Flickr Frans. Quote
Mr Jos Posted January 9, 2022 Posted January 9, 2022 Looks interesting, way past my knowledge. But if it can help to be able to make more complex builds I'm all for it. Good luck and have fun with it! Quote
BrickTronic Posted January 9, 2022 Posted January 9, 2022 (edited) 2 hours ago, fotoopa said: Since there are no extension flat cables available, you have to make them yourself. I did this by cutting a pressure sensor cable to get the Hub connector. With a Raspbery PI Hat I cut the other side of the connector free and soldered an extension to it. Now I can measure all signals with the Pico scope. This way I can see the RS232 values, measure the protocol and possibly connect another type of sensor or interface. Later I hope to give more details about this. A few pictures on Flickr: DSC07753-meet-opstelling by Frans, on Flickr DSC07744-motor-pwm by Frans, on Flickr DSC07711 by Frans, on Flickr Frans. Hello, Philo did Reverse-Engineering of the UART Protocol. You can find his results on his Page : https://www.philohome.com/wedo2reverse/protocol.htm There are also Logic-Analyser Records of some Motors and Sensors at Initialisation Phase and "normal" Data-Transmissions Jo Edited January 9, 2022 by BrickTronic Quote
fotoopa Posted January 10, 2022 Author Posted January 10, 2022 12 hours ago, Mr Jos said: Looks interesting, way past my knowledge. But if it can help to be able to make more complex builds I'm all for it. Good luck and have fun with it! Thanks Mr Jos. Yes it is my intention, especially new inputs. 11 hours ago, BrickTronic said: Philo did Reverse-Engineering of the UART Protocol. You can find his results on his Page : https://www.philohome.com/wedo2reverse/protocol.htm There are also Logic-Analyser Records of some Motors and Sensors at Initialisation Phase and "normal" Data-Transmissions Jo Thanks JO, Yes, I contacted Philo a few weeks ago. He does indeed have a lot of information online, including data records. Most of the recordings are with the earlier EV3 version. There is less info from the new Mindstorms 51515. However, the specs of the new motors are also described. It is a very good source of information. My intention is to use Lego and Fischertechnik together. Using the best features of both systems always gives you extra possibilities. I work mainly with I2C via the FT-TXT but that is connected to a DE0-nano-soc module with a powerful FPGA. That way I have a lot more I/O (120) and outputs like motors servo's at my disposal. I would like to use 1 hub from Lego to connect both systems. A RS232 connection with 1 M baud rate works perfectly. Here an example with FT elements: Pic and place robot make drawing. by Frans, on Flickr I will post new info soon. Frans. Quote
JopieK Posted January 10, 2022 Posted January 10, 2022 Thanks for the info Frans, potentially very useful. Quote
fotoopa Posted January 13, 2022 Author Posted January 13, 2022 (edited) In the meantime, I have done a lot of measurements with the Lego Mindstorms 51515. I measured the different sensors, how the startup happens, how the detection happens, etc. There is so much data that it becomes difficult to present everything. The setup was done with the Mindstorms EV4 and I examined the 6 hub connections. I must admit, the Lego protocol is very large. But a few things are becoming clear anyway. For example, Lego is going to query the all hubs to see if there is a device connected. This is apparently done on an analog signal at pin6 of the hub. Once something is detected there is a CMD request string to ask what is connected. Here a first picture: Powerup hubA 3K3 by Frans, on Flickr Here no device is plugged in but I connected a simulation resistor of 3K3 from the hub pin6 to the GND. This way the Lego hub thinks something is connected and sends a request device ID CMD after the introduction. This request always consists of the data string "52 00 C2 01 00 6E" After which the device should normally respond with a "04" confirmation followed by the full data table and closed with a "04" end value. The master will then also give a "04" in confirmation if there is a valid device present. By using a simulation resistor the device is not recognized. After a wait of 500 ms the Lego hub will check again if anything is connected. The initial detection is apparently an analog detection. A more detail of the analog detection: Lego Mindstorms 51515 motor powerup by Frans, on Flickr Here is a motor plugged in. The Lego hub sees that something is connected and sends a request device ID CMD after the introduction. This request always consists of the data string "52 00 C2 01 00 6E" After which the device should normally answer with a "04" confirmation followed by the complete data table and closed again with a "04" end value. The master will then also give a "04" in confirmation if there is a valid device present. The initial detection is apparently an analog detection. To the right of the picture you can see more data from the data flow. As you can see, the amount of data of the device is quite large, here 532 bytes for the motor. For other devices such as sensors this amount is sometimes even larger. When the device is recognized, a new position of the motor is requested every 100 ms. In between the device can also give an update of the data. I still have many recordings of the sensors. Describing the data is almost impossible. But the structures are similar. The baud rate is 115200. Here is a small program in Python to setup a serial connection to use with my Fischertechnik hardware. Python serial hub by Frans, on Flickr I would use this hub to exchange data with my Fischertechnik system. This way I can send out commands from the Lego as well as vice versa from Fischertechnik. Examples of this will follow later to make both systems work together. The baud rate works well up to 1M. By following the data from the sensors I can also see how Lego, for example, controls the LEDs of the remote sensor. With a small program with blocks you can examine this very quickly. With my Fischertechnik hardware, I have lots of inputs, outputs, motors, servos, analog signals, etc. However, I do not have bluetooth or networking on my FPGA module. Therefore I rely on a serial connection through one of the Lego hubs. Update: foto 1 update with baudrate cmd Frans. Edited January 14, 2022 by fotoopa Quote
BrickTronic Posted January 13, 2022 Posted January 13, 2022 3 hours ago, fotoopa said: In the meantime, I have done a lot of measurements with the Lego Mindstorms 51515 ... Frans. Hello, More Info on the UART Protocol you can find here : https://github.com/pybricks/technical-info/blob/master/uart-protocol.md and also here Frame 52 00 C2 01 00 6E is the Comand "Speed" with the 32-Bit Valie for the UART Speed of 115200Bd. 6E is the XOR Checksum. Jo Quote
fotoopa Posted January 14, 2022 Author Posted January 14, 2022 Thanks Jo. This is very useful information. I still have a lot to read to understand everything in detail. I see that a lot of information are for the old systems, like the ev3. But also for the spike there is quite a bit there anyway. I will then look into modifying my photos with this new information. To establish my own connection to work with FT, I can certainly keep the structure simpler. On my FPGA module I now have about 512 bytes of active data for the motors, servos, inputs, outputs. Especially the inputs I would like to forward to the lego hub. After all, I use a lot of hall sensors with neo-dym magnets of D2x3mm. With that, there is a lot of fast switching. Both the Lego and the FT module can then use them. Frans. Quote
fotoopa Posted February 10, 2022 Author Posted February 10, 2022 (edited) After reading the tips and links I received, I started working on a setup to make Lego and Fischertechnic work together. Since I have no bluetooth connection on my FPGA module and no additional available USB connection I decided to use the HubE as serial connection. For this I have to write everything in Python. That will take some learning! I have made a drawing of the elaborated setup. lego-FT by Frans, on Flickr This shows the data streams between the modules. I first purchased 2 additional Lego modules to be able to split the flatcable. This gives me 2 connections where I can tap into the necessary signals. Hence also the PI Hat PCB to have the other side of the connector. It is high time that Lego makes extension flat cables available. I would then be able to tap the signals from all 6 hubs. This mainly concerns pin5 and pin6 of each hub. The data on these pins runs serial at 115200 baud. I my FPGA I have up to 17 lines available that can process all these signals in real time. So different data values from all hubs can be sent to the FPGA and the PC. Through HubE I can send commands in python to the FPGA. I also use a sync signal for the picoscope. With that, I can control the scope at certain places in the python program to record data. In this way I then have access of real time data for analysis. Here you see on the next picture how this syns works: scope-distance-lights2a by Frans, on Flickr Through HubE I send the command \/\C3. In the program some commands follow for the leds of the distance sensor and a readout of the distance value. On the scope you can see when these commands are passed on to HubA, how the data stream is, how much time elapses in the program etc. On the next picture you see how the value is passed on for the sensor LED and how it is processed in the data stream: scope-distance-lights3 by Frans, on Flickr When reading the distance sensor, we see that the distance is 76mm. The print function in python only returns the integer number in cm, 7cm. The sensor itself does display a mm resolution. The next step now is to work out an example where both FT and Lego will work together. FT works via the TXT Controller and an I2C connection to the FPGA. RoboPro can use the PC screen to display data. For the Lego part the Mindstroms program works, for the scope the Picoscope program. The PC is equipped with 2 UHD screens of 32".On the FPGA side, I have access to lots of I/O signals (max 120 inputs) but also lots of outputs for motors (6 motors per module), servos or digital outputs (max 24). Also I have a DVD remote control, along the Lego side I have the PS4 remote. Frans. Edited February 10, 2022 by fotoopa Quote
Toastie Posted February 10, 2022 Posted February 10, 2022 Now this is what I call a super-nice, wonderful, exciting, fascinating project!!! Wow. I love this. This is my world ... Thank very much for the very nice presentation and all the work you put into that! It becomes quite clear (not the details - to me only that is, but the overall approach) - and this is (for me) always the hardest part. You mastered this! Man, I am still flashed, as I also missed your initial post. Nice, nice, nice. Everything here. All the best - and I hope you keep us updated! Thorsten Quote
fotoopa Posted February 11, 2022 Author Posted February 11, 2022 Thank you Thorsten for the kind words. This gives me courage to post further results anyway. My current handicap are flat cables with connectors for the Lego hub. I can't buy extra sensors to cut those cables down the middle. It's too expensive. I really need to be able to monitor all hub lines.I have just ordered 100 pieces of colored 14mm balls for a project Lego-FT. I already have an idea of what the project should look like. I also like to put some magic into it, something that an outsider has to think about how it works. Meanwhile, I need to write some more routines for the FPGA. This will allow more real-time values to automatically appear on the PC screen. And this without any additional load on the Lego hub. Frans. Quote
fotoopa Posted February 15, 2022 Author Posted February 15, 2022 Reading out all Lego hubs on the PC realtime. Example of reading out the Lego Mindstorms color sensor on the PC. Now 4 values are read out: Light, red, green, and blue color. The RGB values have a range up to 1023, the light value up to about 2660. If there is no object in the picture, the RGB values are just above 0, the light value is -255, so lower than zero. Each hub can be read out. For this, I directly read the signal on pin6 of each hub. This way you listen in on the data being sent to the Lego hub unit. This goes serial on 115200 baud. My FPGA module can read up to 17 lines at 115200 baud. No program needs to be written on the Lego hub, just a powerup is sufficient. This is because all Lego hubs are scanned at powerup and thus identified. To bring the results to the PC screen I use The RoboPro program from Fischertechnic. It connects via an I2C line to my FPGA where all the data is available. I can read out all hubs as long as I have enough flat cables. Since I can now only use 1 flat cable I am limited to 1 hub. I can read out the results of an motor or other sensor in the same way. You can see real time the changes on the screen. I do a readout every 50 msec, which corresponds to 20 reads per second. This is not a hardware limitation. If necessary, I can read out much faster. The I2C runs at 400 Khz. readout color sensor PC by Frans, on Flickr This is a good step forward in getting the Lego to work with my FT. Exchanging commands in both directions will be through 1 hub. This is because I do not have a USB or blueutooth connection on my FPGA. If I use multiple Lego units then I will be able to interconnect them via bluetooth. You can of course replace the FPGA with something else that can be any control or module. The only condition is that you can read all lines sufficiently fast. In an FPGA these are all parallel modules and there is never a problem with speed. Frans. Quote
BrickTronic Posted February 15, 2022 Posted February 15, 2022 (edited) 4 hours ago, fotoopa said: ... Example of reading out the Lego Mindstorms color sensor on the PC. Now 4 values are read out: Light, red, green, and blue color. The RGB values have a range up to 1023, the light value up to about 2660. If there is no object in the picture, the RGB values are just above 0, the light value is -255, so lower than zero. ... Frans. Hello, Does you have records of the TXD-Line (Hub to Sensor) just before observed Values are starting (after initiialisation) ? I think you will get Mode-Combined Data (Mode 6 + 1 + 0) -> 3x Word with HSV Color-Data followed by 1-Byte Ambient-Light (max 100% -> 0x64) and finaly the Color-Index (max 10 -> 0x0A) that would explain the strange max limit of 2660 (0xA64 -> 0x64 0x0A with least significant Byte first) I would expect a Mode-Combining-Command similar to : 0x54 0x23 0x00 0x60 0x10 0x07 or 0x5C 0x23 0x00 0x60 0x10 0x00 0x00 0x00 0x00 0x0F Jo Edited February 15, 2022 by BrickTronic Quote
fotoopa Posted February 16, 2022 Author Posted February 16, 2022 Hello Jo, Thanks for the great info! Yes I have now made the modification. I had considered the 2 bytes as a whole. They were indeed 2 different values. I have made the new updated picture: readout-color-sensor by Frans, on Flickr Now we see a light value between 0 and 100. the next byte is the color that was detected. So here 3 which corresponds to blue. This value is also shown when your Mindstorms program is active in the Mindstorms status screen on the top. I have enclosed a small image of the sensor setup with a blue Lego block. This is much better now because it allows me to directly extract the color from the data string without having to calculate it myself with the RGB values. Meanwhile, I also measured the pressure sensor. Herewith the picture: Lego force sensor readout by Frans, on Flickr The information is taken from the sensor hub pin6. The force sensor passes any change in the sensor to the hub. If there are no force changes the sensor sends the current value after every STX ($02) command from the Lego hub at pin5. There should be no program active, just a powerup of the Lego hub with the connected force sensor. At a minimum, you should have pressed the sensor first. This apparently switches it to another mode where all the information is present in the data string. The string ID always starts with the value $D0 (208). Then follow ( forceb=) the pressure between 0 and 100 where all values below 25 are indicated as 0. The next byte is the switch status. Not pressed he gives 0. From a slight pressure and beyond he gives the value 1. The switch works from the least pressure while the pressure value (previous byte) is still 0. This signal can be used as a simple switch. At the further push you feel a pressure resistance in the button. This is the point where the pressure display starts. The minimum value is 25 and can increase up to the max value of 100. The last value (forcea= 604) is shown here as a 16 bit value. This is not clear to me and probably this 16 bit value should be displayed as 2 bytes. As you can see, in the RoboPro program I can also display status as led lights. Here the led turns green from the moment you press something on the sensor. Only when you fully release the sensor button the status light goes off. For the pressure value reading I have also attached a graphic with dial indicator. The next sensor will be the distance sensor. Later, of course, I can transmit any other information I would like on the PC screen. That will then be via hubE with a duplex 115200 baud line. For that, though, I have to use python. I still have to work out that structure in the FPGA module and then use it in the RoboPro program. Frans. Quote
BrickTronic Posted February 20, 2022 Posted February 20, 2022 (edited) Hello, Color-Sensor : The 16-Bit Values "Red", "Green" Blue" might be : fraction of RGBI (4x 16-Bit Raw-Values Mode 5) or HSV (3x 16-Bit Raw-Values Mode 6), but your observed Values are strange for HSV Also strange that according to Sensor Init-Data all 3 HSV RAW Values should be in Range 0 to 360° but Saturation and Intensity are according the HSV-Model in Ranhe 0 to 100% To can clarify what exacly is mapped, there has to be evaluated the Write-Command (0x54 with 4 Data or 0x5C with 8 Data) from Hub to Sensor that issues Mode-Combining Force-Sensor : The 16-Bit "ForceA" could be : ForceRaw (1x 16-Bit Raw Value Mode 4) or ForcePeakRaw (1x 16-Bit Raw Value Mode 5) Again here, to clarify what is really mapped, can only be clarified when evaluating the Write-Command (0x54 or 0x5C). Your FPGA is able to also read Data on TXD-Line (Pin 5) from Hub to Sensor. Can you do a record of this TXD-Data starting after switch over to 115200Bd or trigger on 0x54 or 0x5C on TXD Line to evaluate the Combine-Mode Data Jo Edited February 20, 2022 by BrickTronic Quote
fotoopa Posted February 20, 2022 Author Posted February 20, 2022 (edited) 4 hours ago, BrickTronic said: Color-Sensor : The 16-Bit Values "Red", "Green" Blue" might be : fraction of RGBI (4x 16-Bit Raw-Values Mode 5) or HSV (3x 16-Bit Raw-Values Mode 6), but your observed Values are strange for HSV Also strange that according to Sensor Init-Data all 3 HSV RAW Values should be in Range 0 to 360° but Saturation and Intensity are according the HSV-Model in Ranhe 0 to 100% To can clarify what exacly is mapped, there has to be evaluated the Write-Command (0x54 with 4 Data or 0x5C with 8 Data) from Hub to Sensor that issues Mode-Combining Jo Thanks Jo for this new info. I have found why I did not find those missing commands from the hub to the sensor. I had not taken enough deep recordings with the scope. The scope is normally set to 5 sec but those commands from the hub are only transmitted around 5.2 sec after powerup. Hence I had not seen the hub CMD 4C and 5C. color-sensor-hub-pin5 by Frans, on Flickr Exactly what these commands mean and how the sensor data should be interpreted afterwards is still not clear to me. Finding all this data is really a puzzle. I now have the scope on 10 sec recording buffer. This is about the maximum to be able to read the data with 100% certainty at 115200Bd with 4 channels. The scope sample rate is then 416 nsec. So for the distance sensor this will also be the case. I just connected it for a moment and it shows 5x the values: 4C 20 00 93 43 00 BC 02 This delay is also about 5.2 sec after powerup. So this gives me a lot of clarity again. Update: Just tested the motor and there the CMD is: 5C 23 00 10 20 30 00 00 00 80 Frans. Edited February 20, 2022 by fotoopa Quote
fotoopa Posted February 20, 2022 Author Posted February 20, 2022 (edited) Meanwhile, I had made a new load test with the medium motor.. The load is 285 gr to spindle diameter 5mm. I monitor the RS lines of the motor hub to read out the information like speed abs position and relative position. Reading out the data goes through my FPGA to the Fischertechnic TXT Controller and the PC. The picoscope is also connected to the hub lines so I can also read out the pwm signals from the motor hub. Here I mainly want to investigate the influence of a motor load and what the pwm signals look like. The requested speed was 70% and the motor had to rotate 2 revolutions (720 degrees) first down then up. After that there was a small rotation of 50 degrees down, 50 degrees up. After this task, the motor position had to be back to the original value. The results can be seen in this photo: hubA motor load DSC07837 by Frans, on Flickr I had requested a speed of 70% but the motor only indicates around 59-61. The duty cycle of the pwm signal when descending is about 58% (484.4us on cycle 834 us). If I look up the same position when rising the speed is around 60% and the duty cycle is now 69% (573us on cycle 834 usec). Consequently, you can clearly see the influence of the load. The results can be seen in this photo:Pico-scope lego hubA motor and readout via TXT by Frans, on Flickr The small python program used: hubA-motor-load-python by Frans, on Flickr However, I have quite a few problems: How can I reset the relative motor position to zero ( not go to zero)? I can't find any working instructions for this yet in python yet with blocks. If you interrupt the program the motor is in an unknown position. On restarting the program, ( not making a new powerup) the relatieve position stay at an indeterminate value. Only at a powerup is the relative position zero but the absolute position can have a certain value. If you go to the absolute position null then again the relative position is changed while I wish to set it to zero during a calibration phase. I find no command to set the motor power to 100%, only an instruction indicating the start power value. This appears to only hold for a maximum of 200 msec. The measured speed always appears to be somewhat lower than the requested speed. In principle, that should not be a problem if you know that. One major limitation is that I don't have extension cables for the hub. The fixed cables are way too short and I also can't take measurements if I don't have the counter connector. With an extension cable these problems would be solved. But I will continue to measure. Soon I may monitor 1 more hub. With that, it will be easier to make time measurements between instructions. Now all the measurements have no delay in the program, just because I listen along to the sent data from the hubs. Frans. Edited February 20, 2022 by fotoopa Quote
Mr Jos Posted February 20, 2022 Posted February 20, 2022 I don't know the programming for the Robot Inventor/Spike Prime, but EV3 had a .reset_angle() to reset a motor on a desired place (when calibrating like my 6DoF). All I found when searching "reset" quickly is for the hub gyro sensor in Spike; hub.motion_sensor.reset_yaw_angle() Perhaps give the motor.reset_angle(0) a try. About the rest, looks fun reading it, but I don't understand anything. But must be great to test/work out how it all works for you and others who then can create fun things with these hubs. Quote
fotoopa Posted February 20, 2022 Author Posted February 20, 2022 Thanks Jos! So far little success, python does not know the instruction. In the help it does say something like set_degrees_counted() but the function is printed in gray and doesn't work either. Normally it should be this one. The python is still in beta. Possibly this will be fixed later on. I did find to control the pwm. and that does work. Measured on the scope the ratio is correct to the specified value. I am looking further... Quote
BrickTronic Posted February 21, 2022 Posted February 21, 2022 (edited) On 2/20/2022 at 4:14 PM, fotoopa said: ... ... Update: Just tested the motor and there the CMD is: 5C 23 00 10 20 30 00 00 00 80 Frans. Hello, Unfortunately Lego did a poor Job on Documentation. The BLE/GATT Profile is long time outdated and has big gaps. The UART Protocol is fully undocumented by LEGO and that what is available is Reverese-Engineering from Fans like Philo. About the UART Messages : 0x4C 0x20 0x00 0x93 0x4C -> 01001100b where 01 is a Command-Message 001 is 2^1 = 2 Data-Byte 100 is Command "Write to Sensor/Motor" 0x20 0x00 are the Data-Bytes that has to be "Written"to the Sensor/Moror 0x93 XOR Checksum 1. Data-Byte : 0x20 is the Sub-Command to set the Mode-Combining 2 is the Comand itself (there is told, that the EV3 Gyro knows also 0x11 and/ot 0x88) 0 specify how much Modes has to be combined and mapped Zero mean, that a previous Mode-Combining is removed 2. Data-Byte : 0x00 not confirmed, but maybe Specify the Mapping for Mode 0, starting at 1st Data-Element 0 identify the Mode itself to be used for Mapping 0 identify the Index-Element Data in the Mode --------------------------------------------------------------------------------------- 0x43 0x00 0xBC 0x43 -> 01000011b where 01 is a Command-Message 000 is 2^0 = 1 Data-Byte 011 is Command "Select Mode" 0x00 is the Data-Bytes to which the Sensor/Moror has to switch 0xBC XOR Checksum --------------------------------------------------------------------------------------- 0x02 -> 00000010b where 00 is a System-Message 000 always 0 because System-Commands does not have Data and Checksum There is only 1 exception for future extensions 010 is soecify the Not-Acknowledge (NACK) that is used to detect a Timeout in UART-Communication (Watchdog) --------------------------------------------------------------------------------------- 0x5C 0x25 0x00 0x10 0x00 0x50 0x51 0x52 0x00 0xC5 0x5C -> 01011100b where 01 is a Command-Message 011 is 2^3 = 8 Data-Byte 100 is Command "Write to Sensor/Motor" 1. Data-Byte : 0x25 there has to be mapped 5 Data (Data can be Byte, Word, Lomg or Float) 2. Data-Byte : 0x00 map Combined-Mode to Mode 0 3. to 7. Byte specifies the sequence of Data in the Combined-Mode 0x10 Mode 1, Data[0] : Reflect [1x Byte] 0x00 Mode 0, Data[0] : Color [1x Byte] 0x50 Mode 5, Data[0] : RGBI [4x Wprd], so Index 0 mean 1. Value that might be "Red" 0x51 Mode 5, Data[1] : RGBI [4x Wprd], so Index 1 mean 2. Value that might be "Green" 0x52 Mode 5, Data[2] : RGBI [4x Wprd], so Index 2 mean 3. Value that might be "Blue" 8. Byte 0x00 used for Padding 0x93 XOR Checksum Note, that the 4. Word (Index 3) of Mode 5 is skipped (Intensity) --------------------------------------------------------------------------------------- Would be interesting what Modes the Force-Sensor would combine. --------------------------------------------------------------------------------------- The allowed Modes for Combining of the Ultrasonic Distance Sensor is unknown or maybe not sent during the Init-sequence because not available --------------------------------------------------------------------------------------- 0x5C 0x23 0x00 0x10 0x20 0x30 0x00 0x00 0x00 0x80 0x5C -> 01011100b where 01 is a Command-Message 011 is 2^3 = 8 Data-Byte 100 is Command "Write to Sensor/Motor" 1. Data-Byte : 0x23 there has to be mapped 3 Data (Data can be Byte (8-Bit), Word (16-Bit), Lomg (32-Bit) or Float (32-Bit)) 2. Data-Byte : 0x00 map Combined-Mode to Mode 0 3. to 5. Byte specifies the sequence of Data in the Combined-Mode 0x10 Mode 1, Data[0] : Speed [1x Byte] 0x20 Mode 2, Data[0] : Pos [1x Long] 0x30 Mode 3, Data[0] : APos [1x Word] 6. to 8. Byte 0x00 used for Padding 0x80 XOR Checksum Jo Edited February 21, 2022 by BrickTronic Quote
fotoopa Posted February 22, 2022 Author Posted February 22, 2022 (edited) Hello Jo, Now that's what I call a nice overview and really good information! I have everything saved and printed out for further use in my measurements and testing. I connected the force sensor for a moment to see the full powerup there as well. Also there, an additional hub CMD can be seen after about 6sec. The transmitted values for the force sensor are: 4C 20 00 93 43 00 BC 02 5C 23 00 00 10 40 00 00 00 D0 43 00 BC 02 ------- The force sensor, not pressed, gives the following data after every 02 request from the hub: D0 00 00 83 01 AD Full pressed sensor gives: D0 64 01 BA 02 F2 Note: The value BA 02 can fluctuate slightly between B8 02 and BB 02 D0 command message 64 --> dec 100 = full pressed 01 switch pressed BA 02 unknown F2 XOR Checksum When the pressure value changes rapidly, the sensor transfers the new data up to every 1 msec. I have now made connection for analysis of 2 hubs and soon I will make a third ( I need to cut the flat cable of one of my motors) to make my own serial line on the hub. There I want to be able to send and receive commands from the lego hub myself. I'm having quite a difficult time with Python. I'm over 78 and that doesn't learn very fast anymore. Especially I am more of a hardware verilog programmer and that is quite a different world where we process everything in parallel and as little as possible with ascii strings. All my processed data was always registers between 8 and 128 bit. The FPGA has 50,000 logical elements. Update: I also connected the led 3x3 matrix to measure a powerup. The Lego hub recognizes the LED matrix and sets the speed to 115200Bd. The led matrix responds by giving the full dictionary after which the hub responds with the End of Transmission character (04). The hub sends 10 msec later pin1 of the LED matrix high. This makes the voltage available to the LEDs. Furthermore, there are no other commands from the lego hub. However, in the RI program, no blocks or python instructions are visible. Still, there are commands possible in python to control the led matrix. The lego ducumentation for this is lacking. However, you can find examples on the internet. Frans. Edited February 22, 2022 by fotoopa Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.