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

[Toastie]

1 hour ago, Toastie said:

Will be back ...

I am back 

And I can report success, again congratulations to you, @Bliss, for these fantastic achievements! And for the clear instructions!

The LEGO Blockly program below, which is connected via HC05 to an Arduino Uno (LegoA2) and b) to an ESP32 WROOM Devkit1 board (LegoA1) at the same time happily turns on/off all outputs of two Interfaces A connected to each board. The communication is fully wireless:

InterfaceA2 was hooked up via the 20 pin ribbon cable to my boxed-in Arduino, InterfaceA1 via single cables, as I need to make a properly wired 20 pin terminal for the ESP board.

InterfaceA2 is fed with 5V Arduino Uno GPIO signals (as per usual), InterfaceA1 with 3.3V ESP32 GPIO signals. In addition to the 6 outputs, the inputs are connected as well - and work perfectly well. The "opto coupler enabling pins" 1+3 of each Interface A are fed with +5V (Arduino: +5V DC output) and +3.3V from the corresponding ESP32 +3.3V pin, respectively. GND is wired as usual in both cases to any of pins 5, 7, ... 19 of the Interface A terminal.

Conclusion:

I believe the ESP32 is a very attractive alternative to the Arduino Uno. However, I also believe that both alternatives should be available, as the footprint of an Arduino Pro Mini (Uno/Nano compatible) "packaged" with an HC05 is still smaller than a fitted ESP board (with at least 8 proper GPIOs exposed). I am using the 30 pin ESP VROOM boards.

Finally: In two of my Interface As, I have routed the internally stabilized +9V DC supply line to pin 2 of the 20 pin terminal and GND to pin 4. I am using this supply voltage for powering wireless BT adapaters (Nano/Pro Mini + HC05), directly plugging in to the 20 pin terminal. I then only need the supply for the Interface A via barrel jack. This is of course also feasible for the ESP32 board.

All the best
Thorsten

 

[Bliss]

34 minutes ago, Toastie said:

However, I also believe that both alternatives should be available, as the footprint of an Arduino Pro Mini (Uno/Nano compatible) "packaged" with an HC05 is still smaller than a fitted ESP board (with at least 8 proper GPIOs exposed). I am using the 30 pin ESP VROOM boards.

There is also a ESP32 MiniKit that has almost same footprint as the ESP8266 D1 Mini, but i'm not sure the same pins I used are available...
But we could probable adapt the Sketch to use the pins avail for the ESP32 MiniKit...

But did you try the real advantage of the ESP32 solution?  I.E., using the same setup with TCLOGO_S (And maybe your QBasic program) in dosbox-x (You must change the serial1 parameter in the dosbox-x.conf file)?

You will then see that the ESP32 can handle the bit bang protocol too!  (And at a different Com Baud rate !)

 

Thank you very much for the testing and clear reports!

Edited 19 hours ago by Bliss

[Toastie]

28 minutes ago, Bliss said:

But did you try the real advantage of the ESP32 solution?  I.E., using the same setup with TCLOGO_S (And maybe your QBasic program) in dosbox-x (You must change the serial1 parameter in the dosbox-x.conf file)?

You will then see that the ESP32 can handle the bit bang protocol too!  (And at a different Com Baud rate !)

 

No, I did not ... but just a few seconds ago, I did.

IT ALL WORKS!!!

TCLogo_S as well as all my QBasic programs!!! Inputs, outputs, everything! This is crazy.

WOW - I am totally flashed. Yesterday, I ordered three ESP32 VROOM Devkit1 boards without exactly knowing what issues may actually hit hard.

Turns out: There was not a single issue! It just works!!!

Well, I'd say: Clairvoyance. 

Thank you so much again!!!

Best
Thorsten 

[Toastie]

@Bliss

The mini ESP (VROOM) boards may actually work, I took a quick look at the pinout. There seem to be more than 6 GPIOs configurable as dig. outputs and at least 2 as inputs?

If so, all what is needed is a +5V (USB) power supply. Or, as said, route the +9V from IntA through a 78L05 and done ... or just put a 7805 inside the 9750 box and wire +5V to pin 2 or the 20 pin terminal.

Best
Thorsten

[Bliss]

54 minutes ago, Toastie said:

IT ALL WORKS!!!

Super!

And in addition, the Power Function IR should also work (with the ESP32 pin 4) in Blockly...

I finally found a better IR Led in my recuparation stock (The previous one was working but the distance was like few cm only, but the new one is quite a few meters) and it works great!

 

40 minutes ago, Toastie said:

Or, as said, route the +9V from IntA through a 78L05 and done

I've been told that you can safely connect a 9V DC source to the VIN (often labeled as 5V/VIN) pin of an ESP32 DevKit V1 because it goes through an onboard voltage regulator, but never connect 9V directly to the 3.3V pin or standard GPIO pins, as it will destroy the chip

I never tried though...

[Toastie]

1 hour ago, Bliss said:

I've been told that you can safely connect a 9V DC source to the VIN (often labeled as 5V/VIN) pin of an ESP32 DevKit V1

Yes, that is what I do in other applications of my ESP32 Devkit V1s. As well as on other boards that have such an input.

I was asking with regard to the mini ESP VROOM board: These don't have a voltage regulator on board, I believe. That is why I would use an 5V regulator. 

I have another question/suggestion, but I don't know if it makes sense. I looked up the pinout of a number of the 30 pin version of the ESP32 DevkitV1 boards, and they seem to be always identical. In the table below, I have compiled the pinout of the Interface A connector (view onto the connector), the current assignment of the GPIOs you have selected (they are all nicely in a row!), and finally the GPIOs as they are on the board (view from the component side)

Now, if the assignment were as in the last row, you could use an 8-wire female/female jumper cable and plug one socket directly onto the ESP pins and the other into Interface A, lower row, pins 6 - 20. I am doing that now with individually separated wires, as I need to cross some. Of course such a wire be soldered to two 1x8 female connectors. 

Actually, this way even the optionally installed internal 9V/GND wiring to pins 4 and 2 would line up nicely. So the entire even numbered row would be 1:1 using a 10 wire cable.

However, I am planning on soldering a 2x10 pin female connector matching the Interface A socket directly to a 10 pin female connector on the bottom row. This connection will be used to mount the ESP board sideways onto the 20 pin connector of Interface A. The remaining 2 wires (3.3V and GND) will be soldered individually from the other side of the ESP board to the 2x10 connector, top row. In other word: The ESP would just pop on to Interface A - and boom, wireless Blockly and Legacy programming at my fingertips!

Question: Is it OK to reassign the GPIOs as per the above table? Maybe even in general? Or is the pinout on your ESP boards different from what I have/found?

Best
Thorsten 

 

 

[Bliss]

1 hour ago, Toastie said:

Question: Is it OK to reassign the GPIOs as per the above table? Maybe even in general? Or is the pinout on your ESP boards different from what I have/found?

I saw that Order mismatch and kept it for you to point this out haha...

I did rearrange the order in the main sketch :-)...

https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino

 

1 hour ago, Toastie said:

I was asking with regard to the mini ESP VROOM board

They are supposed to have a regulator on board too as they have an USB port with 5 volt and the board must bring it down to 3.3v...

But have to double check if it is the same spec etc...

 

 

When you tried the TCLOGO_S, did you also tried the setpower and PWM simulation?

Edited 15 hours ago by Bliss

[Toastie]

1 hour ago, Bliss said:

When you tried the TCLOGO_S, did you also tried the setpower and PWM simulation?

Thank you very much for rearranging the GPIOs! And the little "test" of course .

Yes I did, and I also saw that unsteady blinking of the LEDs. Weird. I shall find one of my Arduinos programmed with my old parallel to serial code. If it does flicker as well that seriously then a) I did not pay enough attention to that matter back in the days or b) something changed in DOSBox-X.

In Legacy mode of the ESP program, what is the baud rate on the BT connection "between" DOSBox-X and ESP? If I understand Gemini correctly, it should be possible to get the Baud rate in DOSBox-X as high as 115200. However, the MODE command does not work correctly and I need to boot DOS 6.22 within DOSBox-X??? Then the mode command should work? Weird.

EDIT: Naa, Gemini changed its mind and said: No way ...

I mean using TCLogo_S, the bottleneck must be serial, as a 1 ms interrupt should be easily emulated, right? And as Alex has just changed the ISA addresses from the 9771 card to HW serial port 1 (COM1), data should arrive at the emulated UART every ms. And when the serial connection to BT is fast enough, I don't see any reason for the flickering to occur? At 9600 Baud yes, but not at much higher Baud rates.

I simply don't have any understanding of how all this works. Do you have any idea?

I tried this in the config file of DOSBox-X, but nothing changed: 

serial1 = directserial realport:COM17 baudrate:115200 bytesize:8 stopbit:1 parity:N txdelay = 0

There is also this serial = nullmodem option (I believe only here the baudrate setting applies ?) but I am too dumb to get it.

Best
Thorsten

 

Edited 14 hours ago by Toastie

[Bliss]

5 minutes ago, Toastie said:

Yes I did, and I also saw that unsteady blinking of the LEDs.

But did you try with real 4.5v Motors connected to the Int.A?
I was wondering if motors really cared about the not that good pwm pulsing?

There Baud rate is irrelevant in ESP32 BT version.  You can set the baud rate of the COM in the end-user app...

I tried in the dosbox-x.conf:  "serial1       = directserial realport:COM14 startbps:19200 parity:n bytesize:8 stopbits:1"
I even tried 115200.
But still can see some inconsistent blinking.  No real improvement between changes in the conf file so I wonder if Dosbox-x take them in account... 

I also tried with the FT245 which is a more direct way (TCLOGO_S DOsbox-x -> COM6 -> FT245 GPIO'S...).
And I can see  inconsistant blinking but maybe less not sure...

I was also wondering about the BT thing is it could really sustain a constant 1ms write/read from TCLOGO_S...
AI told be BT can be faster than that...   But is there other thing to look after too...  For sure there must be some Communication in the ESP32 and in windows...  Don't know...

So, I wonder if this inconsistency can also be seen at the motor level... If not, I will not look further than this...  If it does affect, I don't see much how we can improve using BT solution...

[Toastie]

1 hour ago, Bliss said:

I was also wondering about the BT thing is it could really sustain a constant 1ms write/read from TCLOGO_S...
AI told be BT can be faster than that...   But is there other thing to look after too...  For sure there must be some Communication in the ESP32 and in windows...  Don't know...

So, I wonder if this inconsistency can also be seen at the motor level... If not, I will not look further than this...  If it does affect, I don't see much how we can improve using BT solution...

I completely agree!

To be honest: There is only one "available" program that does PWM using a 1ms interrupt routine, as far as I know: TCLogo for DOS. There is another software, "TC Controller" for DOS, but that has gone into oblivion. I actually contacted TLG, was in touch with the very teachers who used it, got all the way through the LEGO Archives, and after two weeks, they came back with "sorry, IP prohibits any further disclosure". IP? Regarding a program, which was used 35+ years ago? Whatever, TLG was never of >any< help, when it comes to their vintage software. Never. This is why threads like this one and others do exist on EB.

I shall try out incandescent 4.5V LEGO lamps and motors using TCLogo_S PWM. But as far as I man concerned, we should not pay too much attention to native LEGO software PWM: Any timing when using TCLogo is highly accurate, the sensor count rates are accurate, and so turning motors on/off at power level 7 upon reaching defined endpoints is good enough!!! It even works perfectly well in QBasic/DOSBox-X for classic LEGO Technic models. So it works even better with your ESP approach. The maximum update rate of the sensors is more or less Interface A input (sensor) hardware related, not by software. The sensor input circuit is simply bandwidth limited, I have shown that in my Interface A/Atari 1040 ST thread here on EB. The Atari can read faster, than the Interface A can deliver.

If I had to decide, I would just address the miniESP32 vs. ESP32 DevkitV1 board question. And my take is: Use the Devkit1 board, stick it into Interface A and use LEGO Blockly. And if you like, use full power on/off outputs and control your 4.5V model using the light/touch sensors.

What do you think, Yves?

Best
Thorsten   

[Bliss]

1 hour ago, Toastie said:

And my take is: Use the Devkit1 board, stick it into Interface A and use LEGO Blockly. And if you like, use full power on/off outputs and control your 4.5V model using the light/touch sensors.

And Blockly offers a far more precise real PWM using the PWM engine the ESP offers...  So someone can still use PWM with Int.A and ESP32...
I just wonder how Int.A would behave with a PWM output signal to its connector that is 3.3V level...   Might be better use a Logic Converter for PWM with Int.A?

For the choice of ESP32 format, I much prefer  ESP-WROOM-32 Devkit1 board as it as always been reliable in my projects...  I had bugs with some ESP32 Mini clones in the past...
I would probably choose the 30 pin version though...  I had only 38 pins in my stock...

[Ashi Valkoinen]

Hello Bliss,

I am really happy to find your topic and work on Eurobricks. It was only a week ago when I discovered the existance of LEGO Interface B, but seems that thing is exactly what I am looking for - lot of possible inputs and nice amount of outputs.

I made a huge project couple of years ago, a full lego train security system to detect trains (WeDo 1.0 distance sensors), switch points (PF M-motors) and change lights (SBrick Light products) corresponding to the occupation of tracks and position of the switches:

All the motors, sensors are lights are controlled via SBrick hubs (basic, pro, light), the hubs are connected with bluetooth and the program runs online. And here comes my issues.

Bluetooth has some hard limit, I cannot connect more than approx 10 hubs, after that it seems on of the will be always dropped from connection.

The other issue is being dependent on an online surface - what if it disappears?

---

I found multiple topic of yours and still very lot of information, so I found it easier to ask some questions:

1. Is there a programming environment of yours, which can by used offline? No matter the language, I'll learn it.
2. Is there a way to control more than one Interface B, but offline?
3. What do you think, is it possible to use PF-plug distance sensors with converter cable on old (9V) input ports?

I ordered my Interface B on Bricklink just yesterday, and I am really excited about it, what can be done!

[Toastie]

10 hours ago, Bliss said:

I just wonder how Int.A would behave with a PWM output signal to its connector that is 3.3V level...   Might be better use a Logic Converter for PWM with Int.A?

Hmm - I did two experiments:

1. Hooked up Int.A to the Arduino (V2 version, via BT/HC05), and then let a Blockly program ramp PWM from 0 to 250 in steps of 10.
   Response as expected: LEDs on my Arduino light slowly up, as do the LEDs on Int.A.
   A motor 4.5V attached to one output made the corresponding "PWM sound" (maybe in the low kHz range?) at low duty cycle, began to spin at about "70" and then ramped up to full speed.
   A 4.5V incandescent lamp begins to light up at "10" (very low intensity, but clearly discernible), and becomes fully bright at "250".
2. Hooked up Int.A to the ESP32 board. Now it becomes interesting: At PWM "10", "20" max. all three, the Int.A LED, the motor, and the 4.5V light are fully on with no change all the way up to "250".

This may be due to two reasons (or more ...)

1. 3.3V is not enough to drive Int.A with PWM, for some reason I doubt that.
2. The PWM frequency of the ESP is too high??? The electronics inside Int.A is optimized for 1kHz changes at its inputs ... also, I can't hear any motor sound at low PWM settings.

When you did your experiments with the LEDs attached to the ESP: Did they respond accordingly to PWM changes? If so, then it is Int.A causing trouble - either 3.3V or something else (PWM settings? They can be changed to lower frequencies, can't they? If so to the max. kHz range?)

Best
Thorsten 

2 hours ago, Ashi Valkoinen said:

1. Is there a programming environment of yours, which can by used offline? No matter the language, I'll learn it.
2. Is there a way to control more than one Interface B, but offline?
3. What do you think, is it possible to use PF-plug distance sensors with converter cable on old (9V) input ports?

Hi Ashi, you found the right place!!!

@Bliss will certainly reply in much more detail, just briefly:

I know Interface B since long. In my opinion, of all LEGO electronics devices ever produced, Interface B is best suited for train layout control. As it has a serial port, it works with legacy as well as modern computers/programs. The latter via USB2Serial adapters. And with USB you can hook up many Interface B in parallel to your computer. You don't have to use BT at all. Note: It is BT, not BLE, which is much more so prone to dropped connections, as far as I have read.

With regard to your questions: 1 - yes, 2 - yes.
3 - it depends on the nature of the distance sensor. What type is it? Interface B expects the legacy 9V Mindstorms sensors on its inputs, that would be passive = resistors/switches, or active (rotation, light, custom ...). If the distance sensor is, e.g., a REED switch it would work right way. But I doubt that it is such a sensor.

The programming language for Interface B can be anything that connects to a virtual COM port. I prefer @Bliss LEGO Blockly, which operates such ports either on- or offline. I am using the offline version. You can also use the original Control Lab software, QBasic, C, Pascal - thanks to the serial port. 

As said, Bliss will reply in much more detail.

Best wishes
Thorsten

Edited 12 minutes ago by Toastie

[Toastie]

@Bliss

GPIO reassignment is perfect; Now I can use a classic 20 ribbon cable to connect to Int.A by sticking it directly onto the ESP pins and wire +3.3/GND from the other side making swift Arduino/ESP changes possible.

Thanks a lot!

Best
Thorsten