Wapata Posted April 18 Posted April 18 11 hours ago, Wapata said: install CyberMaster in English to test Annnnnd it work. Crazy that nobody corrected that since 1998, the game work in English and not in French ! Maybe I will have the courage to triple check in French later Quote
Toastie Posted April 18 Posted April 18 7 hours ago, Bliss said: Specially when you talk about No serial outputs? (Blockly only use serial...) @Bliss I removed output blocks and let just the timer with no further commands loop. For the input testing I need the output pulses. So I have "no output blocks, no input loop", "with output blocks, no input loop" and "with output and input loops" Best Thorsten Quote
Bliss Posted April 18 Author Posted April 18 (edited) @Toastie, I understand more now. 14 hours ago, Toastie said: with output and input loops For your test, it would have been interesting to have the number of pulses sent vs the number of pulses received (with the counter). I did some test too, with the arduino int A and also the Interface B. (But not with output wired to input) The timer function is not extremely precise as it depends of the overall Execution time. So when we put a preset of 0.05 sec it may ends at elapsed time of 0.055 and more... Even worst when preset is 0.005 s. So when requesting a 100 hz pulse, for sure you will not achieve the exact frequency for the output... Because, a task loop by itself, takes about 0.005s at each iteration... It's because of the yield time that is internal to the task loop. The yield time is important to make the system responsive but it's affecting the task loops scan time for sure. The Serial commands are also affecting to as it takes some time to execute, even if I changed the baudrates to 115200, It just improved slightly the results... The best would be to make int.A like the Interface B... I.e., internally reading continuously the inputs packet and memorize the last state. Then Blockly input instruction would just read the memory... Also, use bytes commands (opCodes) rather then ASCII commands... And maybe, count inputs inside the arduino... I'm going to modify the Int.A logic (arduino and in blockly) to optimize more... Edited April 18 by Bliss Quote
Bliss Posted April 18 Author Posted April 18 (edited) I added in the newest version, an interactive value block that allows to change values while the blockly program is running: (The number interactive value could be used in the power input of Int.A/B output block to vary the speed live, I'm also planning to add a slider block but I'm not sure yet) Using the blue gear , you can change the type of values (Number, Text, Bool and even a custom drpbox) The Boolean is interesting as it gives a checkbox. Edited April 18 by Bliss Quote
Bliss Posted April 19 Author Posted April 19 (edited) I added the Interactive Slider Block (Category "Control" -> "Interactive Control"): With the blue gear, you can adjust the Min Max and Step. In this example, for Int.B, the power can be 0 to 7 step 1. Edited April 19 by Bliss Quote
Wapata Posted April 19 Posted April 19 This is very cool 😀 I don't have my computer near but is there also random numbers (with min and max) generator ? I will try to make a program to make a playable Crusher game. Quote
Toastie Posted April 19 Posted April 19 (edited) @Bliss These are very cool new features! Back to the serial line: At the +100kBaud speed, it works perfectly fine. On 4/18/2026 at 11:11 PM, Bliss said: For your test, it would have been interesting to have the number of pulses sent vs the number of pulses received (with the counter). I did that for initial testing (@19200 Baud) using the "display" block in the pulse generating task. Both, the pulses generated and counted in the main program were always identical. I removed the "display" block, as screen output is always severely slowing down any loop rate - in QBasic and on all my other vintage machines. This may not be an issue on modern programming environments anymore . So I simply removed that block, as I knew no pulse count is missed. I did the same @+100kBaud - always the same numbers in the "display" and "counter" block. The program shown above speeds up by +25% at 100Hz when using the 100+ kBaud serial data line (outputs/inputs) - if this is how it works: Only when using an "out" block, the serial port is called. Now, there are these input/output buffers (in QBasic; these help a lot when connecting to IntB). So I guess there is some buffering, but it is very nicely handled? No single pulse/pulse count loss! Which also means that any further Baud rate increase would not benefit the loop speed as an 6-fold Baud rate increase leads to an overall 25% loop speed increase (using in/out blocks, which is significant!) All the best Thorsten P.S.: For IntA, higher sampling rates in the count block are hardly necessary at all. Edited April 20 by Toastie Quote
Toastie Posted April 25 Posted April 25 (edited) @Bliss I have a quick question: Is it possible to run your latest 115000 baud version of LBlockly and the corresponding Arduino program using an HC05 on pins 0 and 1? I am struggling in getting this to work. Got the HC05 in AT mode using the Arduino IDE (uploaded an empty script first and used the serial monitor to change things on the HC05), changed the UART settings to "AT+UART 115000,0,0" - double-checked with "AT+UART?" and all seems to be OK. I then uploaded your Arduino program again, disconnected the Arduino from the USB port of my laptop to an USB power supply. The HC05 is still connected to pins 0 an 1 of the Arduino. The HC05 is paired with my laptop, it also shows up as a paired BL device in the connect list of LBlockly. When pressing "connect" the blue swiftly blinking LED on the HC05 goes dark, then there is a pause, and then a "no response" error is shown in the LBlockly monitor window and the blue LED on the HC05 blinks again. As said, the HC05 is connected to pins 0 and 1 of the Arduino, in the same fashion as I used for the AT commands. Am I doing something wrong? All the best Thorsten Edited April 25 by Toastie Quote
Bliss Posted April 25 Author Posted April 25 (edited) 5 hours ago, Toastie said: I have a quick question: Is it possible to run your latest 115000 baud version of LBlockly and the corresponding Arduino program using an HC05 on pins 0 and 1? Hi, Did you connect the GND of the Arduino to the GND of the HC05? (And 5v as well) I think the 115200 baudrate might be a little fast... I read that for windows, 115200 could be the very max limit. I'll do some testing. EDIT: GEMINI Says: The HC-05 module's RX/TX logic levels are 3.3V, despite the module often being powered by a 5V VCC pin. The RX pin is not 5V tolerant, so a voltage divider (e.g., 1kΩ and 2kΩ resistors) is required to reduce a 5V Arduino TX signal to 3.3V, while the HC-05 TX can connect directly to a 5V RX. Edited April 25 by Bliss Quote
Toastie Posted April 26 Posted April 26 @Bliss Thank you very much for looking into this! Yes, both +5V/GND come form the Arduino and I used a 1/2.2kOhm voltage divider on the HC05's RX line, as shown here (did that also before on my Nano's I am using on my two other 9750's and the 9751, as they are "installed" across from my computer about 8 feet away). However these run on 9600 and 19200 baud, so yes, that could be an issue. The HC05 can go way up higher - but that does not mean much of course. Best Thorsten Quote
Bliss Posted April 26 Author Posted April 26 (edited) @Toastie, You can try the last version. Since the use of pin 0 and 1 (rx/tx) does not reboot the arduino as the USB does, the wait for "ready" was throwing an error rather than just keep going. I modified the code a little to keep going after the 3 sec boot time required for USB comm. I managed to get it to Connect using the HC-05 (and the Nano) but only with the use of a bi-directional level shifter. But the Outputs don't seem to work for some reason... I'm going to try to lower the baud... In the latest version, there is also a Int.A v2 which I'm testing right now. It does not work yet (at least on my side) with HC-05. This version uses the same output pins but different input pins. I use pin 12 and 13 for inp 6/7 but I'll changed that soon as pin 13 has an internal LED connected to it... EDIT: I replaced input pins on arduino for pin 7 (Inp 6) and pin 8 (inp 7) for the new int.A v2 version. (https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino/Lego9750_V2) This new version uses a simpler byte protocol and is similar to Int.B but at 115200 baud. New version Int.A v2 works great but I had no luck yet with HC-05... I'll keep testing... But you can still use the old version in the meantime. Edited April 26 by Bliss Quote
Toastie Posted April 26 Posted April 26 (edited) 3 hours ago, Bliss said: I managed to get it working with the HC-05 but only with the use of a level shifter. I used the V1 version at 115kBaud, but it does not work with the HC05 - same result: "[16:58:00] Connection cancelled or device not responding." Something is going on, as the blue blinking LED (ready for connection) goes dark for some seconds, and then resumes blinking. I also don't have a level shifter, just the 1/2.2kOhm voltage divider. So 115000 Baud may be too much ... does it work on your side at lower Baud rates, such as 38400? EDIT: I did do an update for LBlockly on your website before testing - does the new LBlockly version work with the V1 version for the Arduino? Or does the new version require the V2 Arduino version? Best Thorsten P.S.: Going to digital pins on the Arduino for IntA is really cool! Edited April 26 by Toastie Quote
Toastie Posted April 26 Posted April 26 @Bliss26-1013 I guess I broke something ... I upgraded to the latest LBlockly version (2026-04-26-1013). Then downloaded the V2 version for the Arduino (this is only one file and no includes, correct?). Now I am getting the "Connection cancelled or device not responding" on both, USB and HC05 COM ports, in other words no more IntA experiments are possible at the moment. Is there a way to revert to Arduino V1 (OK, just use the Arduino IDE and upload the V1 script) - but how do I know which version of LBlockly still worked with the V1 Arduino version? And how may I download that version? I really don't care about V1 - V2 is fine for me as well, but as said, I can't connect even through USB using LBlockly version 2026-04-26-1013. Also, HC05 is just a nice to have for me, but nothing essential!!! If it does not work with the HC05, that is OK! Chances are that I am just too dumb to use the files correctly. All the best Thorsten Quote
Bliss Posted April 26 Author Posted April 26 (edited) 39 minutes ago, Toastie said: I upgraded to the latest LBlockly version (2026-04-26-1013). I might have broken things myself has I'm changing the baud rate to test... Please get the very latest version as I put back the baud rate to 115200 for the Int.A v2 and also v1. Note that the Int.A v2 has a continuous input readings happening behind the scene like Int.B, bu a bit faster. Arduino sends packets every 5 ms or so. That means that using the Input On block does not send serial command anymore. It just read the last input status given by the background packet reader... For the HC-05 problem, i'm still on it. Edited April 26 by Bliss Quote
Bliss Posted April 26 Author Posted April 26 (edited) @Toastie So, I managed to enter AT mode (heard that from you, I did not know about this setting. Default is 9600 so it was working fine with Int.B). AT Mode for HC-05: - You must use an FTDI to configure the HC-05 in AT MODE! - Then press Button on HC05 (or put enable to gnd) and Power on the FTDI AND HC-05. Led blinks slowly twice I think on HC05 to confirm it is in AT mode. - Then using Termite, you configure the port of your FTDI to 38400 baud and connect to the HC-05. - Type command AT+UART to show actual config. Then enter command AT+UART=115200,0,0. - Power cycle the HC-05... I had to google this to find how to do this procedure :-) After that, I tried using level converter but it generates too much noise. So I used the resistor divider trick for the HC-05 RX (Arduino TX) and wired the HC-05 TX directly to Arduino RX. Now, the HC-05 appears to work fine with Arduino v1 and v2 @ 115200 baud but it is slower than using direct USB... But I think it is still usable... With v1 arduino sketch, you can test the commands using Termite or equivalent terminal program by sending for exemple "PORT 0 ON" (no quotes). In windows 11, when you pair the HC-05, it creates like 3 com ports if not more... You must choose the SPP Dev. For me, SPP Dev COM17 is the one working. My wiring to Arduino Nano (Same for UNO): Power Supply 5.2v (+) goes to arduino Vin, (-) goes to GND (in my case, goes to Bread board GND rail). HC05 5v goes to Arduino 5V (NOT Vin). In my case, I wired Arduino 5V to Breadboard (+) rail and HC05 5v to (+) rail. HC05 GND to Arduino GND or GND Rail. HC05 TX goes to Arduino RX0 pin. HC05 RX goes to 2K resisor on divider. The other end of 2K resistor goes to GND. Arduino TX1 goes to 1K resistor. The other end goes to the end of 2K resistor that also goes to HC05 RX... Edited April 27 by Bliss Quote
Toastie Posted April 27 Posted April 27 8 hours ago, Bliss said: Now, the HC-05 appears to work fine with Arduino v1 and v2 @ 115200 baud but it is slower than using direct USB... But I think it is still usable... Oh, nice! I have to try that later today, as I am traveling. Yes, I did all that as well - the fixed Baud rate for AT mode of the HC05 is 38400, and an Ardiuino (or any other terminal program works fine. I am using these BT adapters quite often, they are highly reliable. On one of my 9750, I have modified the 20 pin socket, so it delivers power to an Arduino Pico/HC05 combo. What version of LBockly is working with V1 and V2? I don't have to use different LBlockly versions, right? All the best, Thorsten Quote
Toastie Posted April 27 Posted April 27 @Bliss Back home, tested, works Couple of notes: Instead of the USBtoTTL converter (FTID) for HC05 configuration, you can also simply use the Arduino itself and the Arduino IDE (use the IDE's serial monitor window, with a blank Arduino script) to set the parameters for the HC05 in AT mode. That is what I usually do and learned it back in the days from here: https://lastminuteengineers.com/hc05-at-commands-tutorial/ Note however, that for the AT mode, Arduino D0=RX goes to HC05 RX (3.3V level, use voltage divider), and Arduino D1=TX goes to HC05 TX. And this is where I screwed up (again, did that before): I did not change back to BT mode (HC05 as COM port): Here, as you wrote, Arduino D0=RX goes to HC05 TX, and Arduino D1=TX goes to HC05 RX (via voltage divider) Simple as that ... sorry for causing any confusion!!! All the best Thorsten Quote
Bliss Posted April 27 Author Posted April 27 (edited) 7 hours ago, Toastie said: What version of LBockly is working with V1 and V2? I don't have to use different LBlockly versions, right? Latest version of Lego Blockly has both version of Int.A driver, v1 and v2. They have their own set of blocks. You cannot use Int.A (v1) blocks for int.A v2 and vice versa. It's temporary, eventually, I will remove one of the int.A version after more thorough testing. v2 has different input pins as I said earlier Inp 06 and 07 goes on arduino dig pins 7 , 8 now. The arduino sketch for int.A v2 has only one file and it emulates int.B protocol at some point: It uses the same key phrase to connect and start a continuous packet stream... It uses Byte commands rather than text (not same opCode though)... For input counting, v2 uses same principle as Int.B. 2 bit value that the driver in Javascript handle to make an internal counter. Note that it's counting input changes (0->1 and 1-> 0). Edited April 27 by Bliss Quote
Toastie Posted April 27 Posted April 27 (edited) 5 hours ago, Bliss said: Latest version of Lego Blockly has both version of Int.A driver, v1 and v2. They have their own set of blocks. You cannot use Int.A (v1) blocks for int.A v2 and vice versa. Yes, noticed that, both versions work very well! I shall make the Arduino ↔ IntA cable and then thorough sensor testing (light change, touch) is planned. EDIT: I just ordered 10 of these bare Arduino prototyping boards (for about 1€/piece - no, not Ali, Germany ;), which a bit of luxury - usually I use what I find in my workshop. This damned 2 mm pitch on the output port side of the Uno drives me crazy though. Who on earth came up with that??? These board take care of that. And I can do some LED soldering on the board. And then make the cable, again with an appropriate plug. It is all about the looks - and as the LBlockly software is a) looking really nice and b) works perfectly well for me, this needs some attention! All the best Thorsten Edited April 27 by Toastie Quote
Toastie Posted Sunday at 09:07 PM Posted Sunday at 09:07 PM @Bliss I am done with my Arduino LBlockly "shield" - will show some pictures here soon. Quick question before I do that: The 4.5V light change sensor needs an actual Interface A to convert the small voltage changes it causes when it sees bright or dim reflections of its built-in IR diode. However, the 4.5V touch sensor is a bold on/off switch. This sensor does not require 9750 to induce a 0/1 or 1/0 change on the Arduino digital input pins 8/9. Would it be possible to define two more digital out pins (12/13 would be nice) and have them showing the status of the two input pins 7/8? I did the same thing on my Arduino interface code (with @maehw's mod) - just to visually check whether there is similar input action as on 9750: My Arduino interface running your V2 code has currently 6 LEDs for the outputs. Would be cool to add two more for the inputs. I can also try that myself (void pollInputs seems to be the place), but then we have multiple V2 versions which I don't like ... All the best Thorsten Quote
Bliss Posted Sunday at 11:16 PM Author Posted Sunday at 11:16 PM (edited) @Toastie, You want the sketch to redirect Int.A Inp 6, 7 (Arduino pin 7, 8) to arduino pin 12, 13 defined as output to drive LEDs to show input status? Why not wire LED's directly on the input pins 7, 8? Anyway, I did modify the sketch Lego9750_v2 to redirect input pins 7, 8 to output pins 12, 13. (Note that Pin 13 is already wired internally to the "L" Led on the arduino... https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino Note that Lego9750_V2 is using INPUT_PULLUP for the input pins. The Int.A should already send 0v for OFF (FALSE) and 5v for ON (TRUE) (4.5?) to the arduino input pins. But if you wire a dry contact from a button or touch sensor that uses dry contact directly between ground and the arduino input pins (NO INT.A) , it will be reverse. When Touch not pressed, Input will have 5v, when touch is pressed, input will have 0v. You might prefer to use a 1K pull down resistor on a dry contact switch to have input true when a touch sensor is pressed (5v goes to one pin of button contact and other pin goes to 1k resistor that also goes to arduino input pin and the other end of resistor goes to Gnd). (Not using Int.A as I said) Edited Sunday at 11:30 PM by Bliss Quote
Toastie Posted Monday at 08:03 AM Posted Monday at 08:03 AM (edited) @Bliss Foremost: Thank you so much for being so helpful, supporting, and responsive!!! 15 hours ago, Bliss said: Why not wire LED's directly on the input pins 7, 8? Good question ... my reasoning is (and that may prove completely off): When the LEDs are driven by a separate output, anything connected to the two inputs of the Arduino does not have to drive the "input (10k with pull-up) + LED". I am using blue 5 mm LEDs, which do not need that much current to light up nicely, but still, some mA are flowing. This would be no problem for the 4.5V switch, but who knows what new 4.5V sensor may come as custom additions . According to my lill' circuit diagram I made some time ago, the digital pins of 9750 go H (EDIT: wrong!) LOW when a 4.5V sensor is pressed, or the 4.5V light change sensor "sees dark": The TCLogo "Getting started" manual suggests the same: "The optosensor actually acts like a “dark” sensor. When it sees “dark”, it reports true. When it sees light, it reports false." 15 hours ago, Bliss said: Note that Lego9750_V2 is using INPUT_PULLUP for the input pins. The Int.A should already send 0v for OFF (FALSE) and 5v for ON (TRUE) (4.5?) to the arduino input pins. I guess it is the other way around, so using the internal pull-ups should mimic 9750's behavior? I shall try that out later tonight. EDIT OF EDIT: Finally got out one of my Int.As (9750). And got the TC Logo manual open. Here we go: When I use this program with a touch sensor attached to input 6 the following is happening: Press = closed => Int.A's input 6 LED lights up, as expected. But also ouput 0's LED on both, Int.A as well as Arduino light up. So all is good, right? These double negations drive me crazy ... here is the updated "logic" table: * Bright means something is reflecting the IR light "better than something else". Example: With daylight present in the room the sensor LED is on = dark (although light is around). Making it even darker by putting a black box around the sensor keeps the LED on. Putting a white LEGO plate or anything else reflecting IR light, e.g., putting a fingertip directly onto the sensor "eye", turns the 9750 LED off = bright. This may be counterintuitive, but the main function of the 4.5V light change sensor is the usage with this b/w sectored technic disc right in front of the sensor. One may also use a 4.5V light brick, as it emits +90% IR light in addition to the visible part. In this case the sensor will detect "bright" even from a distance (+10 cm) and "dark" when something is between sensor and light brick. The object interrupting the light beam should not be too close to the sensor, e.g., 2 mm, as then the light of the internal IR diode of the light sensor may be reflected, mimicking "bright" conditions. It would be nice to have identical hardware/software logic. 9750 is detecting LOW on its inputs (sort of pull-up wired), this turns on the indicator LED as well as the opto-coupler LED. The latter though pulls the sensor lines 18 (20) low, as these are pulled-up as well (2.2k). It should be fairly straight forward to implement that behavior per software as well, wouldn't it? These are just ideas. When you have a LEGO model using touch/light sensors, it would be pleasant to just using the same software logic in TCLogo/LEGO Lines as in LEGO Blockly? It seems to exactly do that as is !!! Sorry for the confusion!!! Thanks again and all the best Thorsten Edited Monday at 03:12 PM by Toastie Quote
Bliss Posted Monday at 03:06 PM Author Posted Monday at 03:06 PM @Toastie, I'm surprised because as far as I remember, @Gunners TekZone tested the arduino v1 with his lego lines program succesfully and the arduino v1 uses analog inputs for the Int.A inputs 6,7 and a touch sensor pressed was giving a TRUE = 4.5v... Unless he reversed the input in the blockly block? If I have to reverse inputs in the arduino or blockly I'll do it but this is indeed counter intuitive... Did you make a test with the real int.A yet just to make sure? Thank you for your help! Quote
Toastie Posted Monday at 03:14 PM Posted Monday at 03:14 PM (edited) 24 minutes ago, Bliss said: Did you make a test with the real int.A yet just to make sure? Thank you for your help! I am so sorry, see my edited post above. Everything works as it should. I attached my Int.A to the Arduino and it works fine!!! Regards, Thorsten Edited Monday at 03:34 PM by Toastie Quote
Toastie Posted Monday at 08:54 PM Posted Monday at 08:54 PM (edited) @Bliss, all, after finally getting it (9750 inverts the sensor readings on 6/7, pulling low when active, thus 18/20 outputs go high and vice versa), I finalized my Arduino Uno R3 LEGO Blockly interface. Dedicated to @Bliss! Yes, has been done on bread boards etc. - here is the Arduino prototype board version. I found these a couple of days ago - double-sided, pre-tinned - 1$ per board. If I had known this before ... ;) The board, some call "shield", is nothing more than just an 8 LED carrier with an HC05 Bluethooth socket. I simply cut out the HC05 shape and shortened the board a bit, as there were concerns about touching things below (= the Arduino Uno). I also removed the ICSP header pins (not really required) to make space for the 20 pin header connecting Uno and Int.A. This header could also go on the component side of the prototype board, but it is then a bit "tougher" to solder pins 6 - 20 to the I/O ports of the Uno. And - it seems easier to get the combo into a case ... we'll see. Uno and prototype board attached, again, with HC05 (purely optional): It works with the Bluetooth adapter (outputs 0-5 turned on with LBlockly, input LEDs turned on with a short on Int.A's 6+7). Note, there is no USB connection, just a 9V power plug: It also works w/o HC05, just using the USB connection: Finally, some uninteresting details on soldering the thing together: The plan (made in PowerPoint ^^) And the soldering side: That is it! Now I have a BT/USB Int.A interface for LEGO Blockly, which works without Int.A connected - regarding the outputs. I can just carry the lill Uno with me when traveling ;) Input wise, bold switches, as the 4.5V touch sensors work as well (but logic is inverted). Doesn't get any better! All the best Thorsten Edited Monday at 08:55 PM by Toastie 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.