Project: Programs to allow interactions between old Lego Control Interfaces (RCX, Lego Interface B, others?)

[Gunners TekZone]

30 minutes ago, Bliss said:

I didn't recall you had a Int.A but I'm not surprised either ;-)

Hah... Yes, I have one on my Commodore 128.  But I recently got a 2nd for use on an Apple IIe Clone I repaired and "fixed" a DIY Rebooted 9767 interface card for it.
 

30 minutes ago, Bliss said:

The Arduino Mega should work too since it has more PWM pins.  And the pins used in the Arduino sketch I provide in my github are also available on the MEGA as I can see.

The MEGA uses different OUT pins (8-13)as they are all PWM capable on it, and some of the ones used on the UNO are used for the LCD shield.

30 minutes ago, Bliss said:

Did you use the sketch I provide?  I did not only changed the baud rate to 19200 (not 192000 as you put in your post).  I had to tweak the main sketch a bit to aquire more speed and stability.

Aside from the BAUD typo in my post  (more zeros better, No?)...  I did load it on an Arduino Nano (AFAIK same pins as UNO), but Blockly tries to connect (I see LEDs on the nano flashing) however, it refuses to acknowledge it. 

So I gave up for the moment and been playing with the MEGA, with a couple of LEDs representing a couple of Int-A ports (Still too lazy to make up a proper cable ).

 

30 minutes ago, Bliss said:

I don't own an Int.A myself

@evank offered you one a couple of times... I recommend you don't turn down such a generous offer from a fellow enthusiast! 
 

 

Edited yesterday at 11:05 AM by Gunners TekZone

[Bliss]

@Gunners TekZone,

Something though I have not figured out as I'm not an Arduino expert, is about the serial com port of the UNO shared between the USB and pin 0 and 1.

I can upload the sketch through the virtual com port created when I plug the USB com port of the UNO to the PC.

But I cannot use the same com port to commect to blockly!

I have to use a separate FTDI on Pin 0 and 1 which create a different COM port and then it works with blockly with this COM port.  But not the USB COM port...

 

Edited yesterday at 11:23 AM by Bliss

[Gunners TekZone]

I was wondering what your program was doing with just the UART (USB) Serial command in play.  The UNO (and Nano I am using) only has the single UART/USB/Serial port.  You would need to use Software Serial if you needed to talk to a device and show data on a terminal program.  Or use a MEGA that actually has multiple hardware serial ports (pins 14-19), aside from the primary  UART/USB one.

I just plugged the Nano, via USB,  into my computer that is running Blockly, then tried to Connect Int.A via that COM port... Is that not how it is supposed to go?
Oh, I just read your edited post... Yup, it must be using SoftSerial in the Lego9750.h library??  Hmm... No??  

Edited yesterday at 11:50 AM by Gunners TekZone

[Bliss]

5 minutes ago, Gunners TekZone said:

I was wondering what your program was doing with just the UART (USB) Serial command in play.  The UNO (and Nano I am using) only has the single UART/USB/Serial port.  You would need to use Software Serial if you needed to talk to a device and show data on a terminal program.

I just plugged the Nano, via USB,  into my computer that is running Blockly, then tried to Connect Int.A via that COM port... Is that not how it is supposed to go?

Well,  the exact same way of doing things with the UNO did not work for me.

I had to use an external FTDI where FTDI TX goes on UNO RX (Pin 0), FTDI RX -> UNO TX  (Pin 1).

Then it works...

Edited yesterday at 11:41 AM by Bliss

[Gunners TekZone]

8 minutes ago, Bliss said:

I had to use an external FTDI where FTDI TX goes on UNO RX (Pin 0), FTDI RX -> UNO TX  (Pin 1).

Hmmm... I haven't messed with Arduinos in awhile, but I am sure that pins 0/1 are the same Serial connection as if plugging into the USB connection (but the COM port will change depending on what TTL-Serial device you are using, the external or the one built into the Arduino)

Edited yesterday at 11:49 AM by Gunners TekZone

[Bliss]

13 minutes ago, Gunners TekZone said:

Hmmm... I haven't messed with Arduinos in awhile, but I am sure that pins 0/1 are the same Serial connection as if plugging into the USB connection (but the COM port will change depending on what TTL-Serial device you are using, the external or the one built into the Arduino)

I know.  If I want to upload the sketch, I have to disconnect the pin 0 which I use for the FTDI...

But still, you will not be able to use the built in USB port for some reason...

Might be that the USB port of UNO is forced to a certain speed when used?

 

EDIT:
I think I found why...

I used termite to check what is going on.
With termite, I'm able to communicate using the USB port!
But when I open the port, the arduino send immediately a string which I do not receive when I use an External FTDI...

So I will make some changes and let you know when it works with the USB port

Edited yesterday at 12:07 PM by Bliss

[Gunners TekZone]

8 minutes ago, Bliss said:

Might be that the USB port of UNO is forced to a certain speed when used?

No,  That is set by Serial.begin() and must match with the speed you are using in Blockly.

I dunno??... I can't seem to get my Nano (running your simple sketch and associated libraries) to connect, either via USB or external TTL-Serial and their respective COM ports...  The connection LEDs flicker then Blockly says Connection Canceled or device not responding.

[Bliss]

@Gunners TekZone, thank you, I'll get back to you when I managed to make it work using the USB port.

[Gunners TekZone]

@Bliss  I am a little foggy headed at the moment... and will be heading to bed anyway   But as I skimmed through the Lego9750.h and Lego9750.cpp  It seems that these libraries are using the primary Serial port to communicate with a Serial Monitor (IDE or terminal program)... So it CAN'T also use that port to communicate with Blockly!  Or at least when the sketch is set to Verbose mode?? I dunno... I would have to be much clearer headed to follow the code properly.

What I think you need to do is find a way to add in a Software Serial port to communicate with Blockly while keeping the existing Serial Monitor option for diagnostics... Or vice versa... Whatever works best to also control the LEDs and monitor inputs as needed to "emulate" an Int-A

Edited yesterday at 12:21 PM by Gunners TekZone

[Bliss]

@Gunners TekZone, it is working for me with an external FTDI with no change to the code.   (Rx -> Tx, Tx -> Rx, Gnd->Gnd).  But not with USB Com port of the UNO...  Which make me think It could also be a driver incompatibility with the Chrome WEBSERIAL API...

I'll dig more...

[Gunners TekZone]

Ya, I think Verbose mode is off by default.  Strange that I can't get it to work via FTDI on my nano.  It tries, but no go.

Anyhow, I am off to bed (it is 5am after all... a few hours later than usual for me   ) so will try again later.

[Toastie]

@Bliss, @Gunners TekZone

Hmmm, 

I cannot add much to the discussion. However, when I made my lill' Nano serial2parallel adapter, I noticed that the Nano never shows up as a COM port in device manager (but somewhere else as something else in the manager, I forgot where/what that was)

So for programming the Nano, I am using the built-in mini-USB connector as usual (which routes to Nano pins 0 and 1).

For actual serial2parallel conversion, I am using a Ser2TTL (or USBB2TTL) adapter, connected to pins 0 and 1 as well. I do have a little on/off switch between the TX line of the Nano and the Ser2TTL adapter, shown in this picture:

https://www.eurobricks.com/forum/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/#findComment-3580886

When programming the Nano, I switch off the Nano's TX connection to the Ser2TTL adapter, when running in plain serial2parallel conversion, the switch is connecting both.

But this is not even what you are talking about, is it?

Best
Thorsten

[Bliss]

@Gunners TekZone

Please update Lego Blockly to the latest version : Version: 2026-04-06-1230

My Arduino is a Clone from Aliexpress.  And yours is probably a clone too...

So it is using the not so good CH340 Uart ...  After some testing, I found out that after connecting to the COM port, it takes some time before we can write/read anything to it...

So I started to add a delay, at first, 1 sec but was still not working then I put 2 sec delay and now it appears to work fine.

Also, by default, the Sketch for the arduine was setting VERBOSE ON so changed that too but it should work even if you do not update the sketch...

Because, when I connect, to make sure it is really connected, after the 2 sec connect delay, I send VERBOSE ON and THEN VERBOSE OFF and wait to receive VERBOSE OFF feedback.

So now for me it works directly with the Arduino UNO USB port.  NO NEED FOR AN EXTERNAL FTDI.  (Anyway, if the external FTDI happens to be a CH340, it will probably fail)

Anyway, try this version and let me know.

Thank you!

 

EDIT: AI ANSWER Why using the Arduino USB port to connect takes time:
 

When you open a serial connection to an Arduino UNO (or any board using CH340/ATmega16U2), the USB‑serial chip does something that FTDI chips do not do:

⭐ It toggles the DTR line → which resets the microcontroller

This is the key.

Opening the serial port triggers:

• DTR goes LOW

• The ATmega328P resets

• The bootloader starts

• The bootloader waits ~1–2 seconds for a sketch upload

• Only after that does your sketch begin running

• Only after that does the board respond to commands

Edited yesterday at 05:33 PM by Bliss

[evank]

6 hours ago, Gunners TekZone said:

@evank offered you one a couple of times... I recommend you don't turn down such a generous offer from a fellow enthusiast! 

I have plenty of them and will happily share with anyone who is pushing the boundaries + doesn't necessarily have the cash to buy one retail.

[Toastie]

@Bliss

Now I got it (timer wise for Interface B):

Quick question: When the program runs and a button block has not the focus (or what ever it is called, when there is this yellow outline around the block), it mostly needs two clicks to activate the button action. Sometimes one click is enough. That would be the case in Task1, when I clicked the upper button twice, which turns output C on. After that, only 1 click is required to trigger the action.

When I then go back to the main loop and click to end the program, I first need to have the focus on the button, the next click will end the program.

This is what it is, right? It is absolutely not a big deal, I am just asking, because generally, it is my fault when it does not work as (I) expected.

Best
Thorsten

[Bliss]

@Toastie,

Yes for the two clicks bug...  I tried to use copilot to help with this. 
Copilot is always very positive in his replies but sometimes what he proposes just does not work and then we are good for dozens of iteration ask / reply and I was fed up at some point because beween each copilot suggestions, often his suggestions break something...

However, I might try to ask other AI for a solution on this if there is one...

[Bliss]

@Gunners TekZone,

Please update the sketch on your arduino you use to test blockly.

I added a Println("READY") in the setup of the Arduino.

Then when we connect with blockly to the arduino, it is going to reboot it and I wait until I receive the "READY" string...

[Bliss]

@Toastie

Please update to the latest version.  The Interactive Button block 2-click bug seems to be gone now...

Version: 2026-04-06-1456

[Toastie]

2 hours ago, Bliss said:

Please update the sketch on your arduino

@Bliss

These are the files on your GitHub, right? As said, I am far away from home (and hardware), other than Interface B (which "glows" with pride on the desk here). Next week I am back home - and there are some Arduinos floating about 

1 hour ago, Bliss said:

seems to be gone now

No, sorry, doesn't "seem" to be the case - it >IS< gone 

What to say other than: Unprecedented (for me). The LEGO Blockly software is so powerful - and I can, >in real time<, ask about my problems, challenges, proposing ideas ... it does not get any better. Interface A and LEGO Blockly - that is another new dimension.

Here is another question regarding the USB connector approach for Interface A communication via COM ports: My 3 Interface A's are hooked up (using manual serial port switches) to various vintage computers, and in addition to an Arduino Nano or Pico/HC-05 combo. These rely on BT2TTL adapters connected to ports 0/1 of the Arduinos.

As far as I understood your conversation with @Gunners TekZone, this is not causing any trouble, as you do that anyway, correct?       

All the best
Thorsten 

Edited 23 hours ago by Toastie

[Bliss]

39 minutes ago, Toastie said:

These are the files on your GitHub, right?

Yes ! The sketch file folder (must get the whole folder) is available here: https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino/Lego9750

And you can also easily find the sketch clicking the link "Source Code" in the footer bar of the Lego Blockly web app.

 

39 minutes ago, Toastie said:

Here is another question regarding the USB connector approach for Interface A

For now the only way to have the Interface A working with Lego Blockly app, is through an arduino.  This concept has to proven working but I used a sketch done by someone else that has been proven to work.

Of course you may use any arduino alike boards you want as long as you use the sketch I provide as the base.

Then, if you use pin 0, 1 on an arduino MEGA for ex, I think you have to use Serial1 in the sketch rather than Serial.

Pin 0, 1 in the UNO use the same as the internal USB Uart.  But I think I read that it was different for the Mega...  So it might be different on other type of board...

So in the .ino file, there are 4 places where the "Serial" is used:

#include "Lego9750.h"

String ByYourCommand;

Lego9750 brick; 

void setup() 
{
  // put your setup code here, to run once:
  Serial.begin(19200);
  brick.Port_Initialize();
  Serial.println("READY");
}

void loop() {
    if (Serial.available()) {
        String cmd = Serial.readStringUntil('\n');
        cmd.trim();
        if (cmd.length() > 0) {
            brick.Parse_Command(cmd);
        }
    }
}

 

You may also have to modify the pin configuration that is defined at the top of the .h header file :
The digital pins must support PWM. (Appears that UNO and Nano share the same PWM Digital Pins...)

 #define PORT0_PIN 3
 #define PORT1_PIN 5
 #define PORT2_PIN 6
 #define PORT3_PIN 9
 #define PORT4_PIN 10
 #define PORT5_PIN 11
 #define PORT6_ANALOGPIN 0
 #define PORT7_ANALOGPIN 1

 

EDIT: I just uploaded the sketch to an arduino Nano and it uploaded fine...

Edited 22 hours ago by Bliss

[Toastie]

6 minutes ago, Bliss said:

Pin 0, 1 in the UNO use the same as the internal USB Uart.  But I think I read that it was different for the Mega...

That Mega issue could very well be - but I am looking at the Nanos and Picos (and UNOs for testing) as I like to keep the serial2parallel translation small, simple, and efficient. The 8 LEDs connected to the Arduino boards suffice to tell me what's going on. Interface A is simply a power amplifier.

And now of course this includes your implemented LEGO Blockly <-> Arduino protocol enabling PWM!

PWM thus should also be in reach for my QBasic programs, once I know how LEGO Blockly is communicating with the Arduinos. As you said this is based on the LVL1 protocol, it seems doable!

All the best
Thorsten

   

[Bliss]

1 hour ago, Toastie said:

but I am looking at the Nanos and Picos (and UNOs for testing)

I just switched to the Nano for my test and it works fine ... to drive LEDs...  But if I read well, the dig pins can provide max 40 ma and I don't know if it is enough for the Int.A...

Edited 21 hours ago by Bliss

[Gunners TekZone]

11 minutes ago, Bliss said:

But if I read well, the dig pins can provide max 40 ma and I don't know if it is enough for the Int.A...

It will be fine, the Int-A connector has optical isolation, so the drive controller is only powering those.  I think that is also the reason for the 5v pin, to power the interface side of that opto-iso circuit.

 

5 hours ago, Bliss said:

EDIT: AI ANSWER Why using the Arduino USB port to connect takes time:

Ah, so good sleuthing.  Yes, My clone has that CH340.

I am just waking up, so it may be awhile before I get to testing.

[Toastie]

33 minutes ago, Bliss said:

But if I read well, the dig pins can provide max 40 ma and I don't know if it is enough for the Int.A...

It is more than enough, my Nanos are doing their job well on Interface A.

40mA is way(!) more than required. The ULN2003 Darlington-Transistor-Array input driver used in Interface A's does virtually need no input current ...

Best
Thorsten

15 minutes ago, Gunners TekZone said:

the Int-A connector has optical isolation, so the drive controller is only powering those.

Well I guess the connector is driving the ULN2003, which is driving the opto couplers? These need some solid current to saturate, but this is not exposed to the connector.

Best
Thorsten

15 minutes ago, Gunners TekZone said:

to power the interface side of that opto-iso circuit.

True that. But this is a solid 5V connection, the Arduino outputs don't have to cope with.

Best
Thorsten

Edited 21 hours ago by Toastie

[Gunners TekZone]

16 minutes ago, Toastie said:

Well I guess it is driving the ULN2003 which is driving the opto couplers?

Yes, you are correct.  It was the input lines that I was thinking about, being directly wired to the connector.  But they all are powered by the 5v line on same connector.

I think this is an accurate resource of that, that someone else made.  Still working on 1st coffee, so I could be hallucinating enough to rival AI