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 Monday at 01:16 PM 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 Monday at 05:22 PM 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 Monday at 07:04 PM 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 Tuesday at 08:55 AM 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 

[Bliss]

5 hours ago, Toastie said:

When you did your experiments with the LEDs attached to the ESP: Did they respond accordingly to PWM changes?

DonT, you have LEDs too attached to the ESP in addition to the Int.A?

On my side, the LEDS attached to ESP32 GPIOs are dimming smoothly on the full range 0-255.

 

In Arduino IDE, the code to adjust the frequencey is at line 241:
 

// =========================================================
// PWM (ESP32 LEDC) for Blockly outputs
// =========================================================
const int LEDC_CHANNELS[6] = {0,1,2,3,4,5};
const int LEDC_FREQ = 20000; // 20 kHz
const int LEDC_RES  = 8;     // 0-255

I changed the 20000 for 1000.

Could you please try again? 
(I also read the 3.3v may also affect, so if not better, using a logic converter may help too.  But 20 kHz was way to fast for sure).

Use the sketch: Lego9750_PF_ESP32_V2 in the following folder:
https://github.com/BlissCA/lego-blockly/tree/dev/SketchArduino

 

[Toastie]

7 hours ago, Toastie said:

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.

@Bliss

I hate to cite myself and mangle with code from other people without asking for permission - but I could not resist:

PWM works with the 3.3V ESP32 GPIOs connected to Int.A, when the frequency is changed to 1kHz.

I just edited your ESP32 code in the Arduino IDE 

// =========================================================
// PWM (ESP32 LEDC) for Blockly outputs
// =========================================================
const int LEDC_CHANNELS[6] = {0,1,2,3,4,5};
const int LEDC_FREQ = 1000;  // 1 kHz
const int LEDC_RES  = 8;     // 0-255

and PWM works like a charm on Interface A! I believe it is the electronics inside the interface, which is behaving erratically at 20kHz? Or the 3.3V are not enough for 20 kHz? Anyway, the 4.5V motors and lamps don't need 20 kHz at all. But I don't know. All I know it works at 1kHz  Even the motor make happy sounds when PWM is at low duty cycle.

Here is the ESP board attached directly to my modified Interface A, which has +9V on pin 2 of the 20 pin connector and GND on pin 4: Just one cable required: Power for the Interface A:

 

(It's the thing on the right side - very good photography ...)

Here is are better views; ESP board attached (the red and white wires provide 3.3V and GND for the opto couplers), component side, and solder side:

 

That's it for the moment ...

Best
Thorsten

 

3 minutes ago, Bliss said:

I changed the 20000 for 1000.

I guess you were some minutes faster ... I'd call this huge success!!!

The remaining question is: What is the PWM frequency in the Arduino version? Because that works with PWM! If that is running at 20 kHz as well - well than the 3.3V don't allow 20 kHz. If it is lower (and I believe so, as I can hear the motor humming at low PWM. I am 64 years old, have developed a nice high frequency backgroud sound in my ears (music was always too loud back in the days ^^), so that everything above 8 kHz is gone .   

Thanks a lot and all the best
Thorsten

Edited Tuesday at 03:15 PM by Toastie

[Bliss]

24 minutes ago, Toastie said:

I just edited your ESP32 code in the Arduino IDE 

We posted almost at the same time :-)

I changed the freq already in the github.

 

24 minutes ago, Toastie said:

Here is the ESP board attached directly to my modified Interface A, which has +9V on pin 2 of the 20 pin connector and GND on pin 4: Just one cable required: Power for the Interface A:

This works well because you use the 30 pin ESP32 Devkit which is great indeed.

With the 38 pin version, there is a GND pin between the 13 and 12 pin that would break your setup and also the Vin/Gnd are not at the same location...

Using the 30 pin is really the best then and It makes a really small fooprint wireless adaptor !

Modifying the Int.A to get the 9V on pin 2 is a must for sure!  

 

Thank you for your time testing all this!

Edited Tuesday at 03:34 PM by Bliss

[Bliss]

10 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?

Hello Ashi,

I'm mostly developping the Lego Blockly project these days...

You may also look after the Python module for lego Interface B:  https://github.com/BlissCA/LegoBpy

Python is a fairly easy language to learn AND if you download and install Thonny IDE, it make the Python learning experience easier according to me.
I believe for Bigger projects, it might be a good option.
And you can use many Int.B at once.  The github has a Readme to explain how to use.

I also made another thread for a MicroPython version that runs on an ESP32 MicroController which is also very Cool as it makes the ESP32 autonomous.
This is a bit more advanced though if you're not familiar with MicroControllers...
I did not worked more on the micropython driver to add more features but as far as I remember, it was pretty solid...
See: 

 

LEGO BLOCKLY

Since few months now, I'm working on the Lego Blockly project.
Lego Blockly is running in a Browser (Chrome or Edge) but it is possible to use it offline.
When you visit the page the firstime, there is a small TV icon on the right of the Address (URL) bar and if you click on it, you can "Install" Lego Blockly.
Note that it is still using Google engine but it is suppose to run without access to internet.

Lego Blockly page:  https://blissca.github.io/lego-blockly/

You can connect more than one Interface B and the programming language is based on Blockly, like lego blocks you connect together.
I think it is very simple but it needs some time to get the hang of if.

It supports many Lego Devices and more needs to be added eventually.
I did not implement any thrid party devices like SBrick that I just learn the existance by you :-)
I may in the futur add support for other brand devices if the interest is there and if there is public information available on how to interface with them...

It is easy to play with Lego Blockly but I'm not so sure it is well suited for Big projects though that will run for many hours non stop...
The code area is infinite, you can zoom, scroll etc but I read that running programs that have 5000-7000 blocks may become slow and laggy... 

While it runs a program, the Page needs to have focus all the time and you must disable Power saving on your PC etc...

But you may try it as it is really VERY super simple to use.  No special software to install.

And do not hesitate to ask question here and talk here about your experience and even suggest features so I can improve Lego Blockly.

Thanks for your interest.

 

There are also projects by others you may look after like @Mr Hobbles BrickLogo:  https://github.com/openbrickproject/BrickLogo/tree/main
It is also very well documented!
It's using LOGO software like the original Lego TC Logo and LEGO DACTA Control Lab...

I'm pretty sure there are others available.

Edited Tuesday at 05:13 PM by Bliss

[Bliss]

9 hours ago, Toastie said:

Interface B is best suited for train layout control

But Interface B still has some current limitations... 
I doubt it can run 8 train motors at the same time no?

And how you do when you have long 9V train tracks...  There must be some load loss over the distance?

I admit I don't know much about those Lego Trains...  I already had a 9V train though...

[Ashi Valkoinen]

37 minutes ago, Bliss said:

But Interface B still has some current limitations... 
I doubt it can run 8 train motors at the same time no?

And how you do when you have long 9V train tracks...  There must be some load loss over the distance?

I admit I don't know much about those Lego Trains...  I already had a 9V train though...

Thank you for your detailed explanation in the previous comment. I will give a try to Thonny and the Python module. Basically I have no prior programming studies or experience, I find always the hardest part to install the right versions of programming environments and get started. Learning a language is okay, I submit this for my hobby. I'll also take a look at your Blocky, my previous impression was that it needs your site to reach and works only if your site in on - just like the pro.sbrick.com where you can save your programs, but everything is in cloud.

Basically my train concept is different from automated train control, at my approach trains are all driven by individual drivers at club shows, but all of them drive as the corresponding signalling tells them to drive. My previous work based on SBrick Pro controls no train, it manipulates the switches, lock the routes set for different trains and turns green, yellow, red signals. When a train passes a free-to-go signal, it turns the signal automatically back to red.

Maybe this sped up video shows the approach better, people with phones on their hand drive their train, but they go only when the route is set and the signals on their track shows a free aspect.

 

So basically what I will need to make this work wired, using Interface B, without Bluetooth and internet connection:
- 9V Light sensors to detect trains. A bright light source (like PF ledlight) is put in front of the sensor, at the opposite position of the train track, when a train passes by, the measured brightness decreases, when train passed, it increases back to previous value.
- My PF M-motor can drive the switching mechanisms as built in currently, each point needs a power output.
- Modified PF ledlights (modification: always one led lits up of the two depending in polarity) will go to signals, one power output needed for each two lights.
- Rotation sensors are mechanically connected to the switching mechanism, so a feedback for the positions of the switches can be given to ensure safe rute.

And all these are connected with the logic built up - if Blocky gives enough coding possibilities (your block are really similar to SBrick Pro), then there, if I can't store enough variables, number, boolens, etc., than I need to move for Python and Thonny. I went around 10k blocks in SBrick Pro, my station control is a really complex thing.

Thank you once again for your feedback and I'll let you know if my Interface B arrived and I can test things.

Unfortunately adding SBrick to your project will require also handling bluetooth connection, but as the SBrick as company fades away, their services won't last forever, so many user would be happy if you can give a software solution for them to keeps their bricks alive. (It is an unfortunate story, SBrick was one of the first Bluetooth receiver units, 3 years before LEGO intrduced PU, and still superior compared to LEGO products in connectivity and features. The company produced 15k-20k SBricks in total, and couple thousand SBrick+ units which could handle WeDo 1.0 sensor inputs as well, but their design got copyrighted with someone else and they had to stop to produce their own product they didn't own anymore... :( ) 

[Toastie]

1 hour ago, Ashi Valkoinen said:

Unfortunately adding SBrick to your project will require also handling bluetooth connection

I believe that SBrick (as well as PU and others) connect through BLE and not BT, correct?

Best
Thorsten 

[Toastie]

2 hours ago, Bliss said:

But Interface B still has some current limitations... 
I doubt it can run 8 train motors at the same time no?

No, it can't. But as Ashi wrote: Interface B is perfectly suited to operate switch pints and lights, as well as reading any 9V compatible sensors. This is where Int.B outperforms any other LEGO "interface", as far as I am concerned.

The voltage drop along long stretches of track is considerable; this is why I have a spider web of good gauge wires connecting to 9V track all over my layout. My trains are running with power pick-up from the track (held at 15 V DC using an old laptop power supply ), feed that via bridge rectifiers to rechargeable batteries, which in turn power either PoweredUp hubs or PF receivers. This way I can mix all plastic and 9V track, uses wyes and reversing loop without problems; I just use 1 piece of plastic track for insulation to prevent shorting. All PF receivers are RF (433 MHz) operated using stone-old low power RFM transmitters and receivers. 16 years ago, I ran my first three remotely controlled trains using RCX'. The RF components were powered from an active RCX input. Well I still have them ... my 12V and 4.5V trains are also equipped with this "tech" 

As far as I am concerned LEGO Blockly is really perfectly matching with the switching and detection tasks of a train layout, even if it is large. It is visual, following logical paths. And it is multitasking as well! It does not get any better. In this application case, timing is also not that critical, I'd say. And with Blockly, everything is scalable. And lastly, I believe a wired serial connection hardly ever "drops", don't you think?  

Just my two cents. OK, I have to admit, I love LEGO Blockly.

Best
Thorsten

[Toastie]

@Bliss

I did another test with the ESP/Int.A combo.

It appears as if almost the entire PWM duty cycle range (0 to 255, 1kHz) is nicely covered when using 4.5V actors (motor, incandescent light bulb):

1. A no load 4.5V motor begins to rotate at PWM level 40 (~15% duty cycle) and maxes out at level 220 (~85% duty cycle)
2. An incandescent light bulb in the yellow brick spans the entire PWM range. Optically it is more responsive at low level intensity changes, but this how our eyes work.

As a result, the 255 PWM step range is spot on!

This reflects a bit TCLogo's PWM handling (as they have defined PWM signatures for the power levels 1 - 7, which are non-linear): The lowest power level 1 has more on time than the corresponding percentage (1/8 = 12.5%) , they begin with 25% see here:

I thus believe that they did that, because a no-load motor is not present in a Technic model/machine in analogy to the Carnot machine . On the other hand, they clearly preferred good motor performance when using PWM. 

This also means that in TC Logo lights are intended to be used more or less as on/off signals. I experience the same thing, when using TCLogo to light up 8 4.5 lamps at different power levels. Was not as linear as it could be ...

Conclusion: With LEGO Blockly we can nicely adjust the "active" PWM level range for 4.5V motors and 4.5V lamps. Motors start at about PWM 50 ... 60 (w/ some load), lamps almost cover the entire range.

Which motivates me programming an optical vue-meter, as @alexGS already suggested in the 9750/9771 thread, when I tried the power levels in TCLogo ...

Best
Thorsten

[Bliss]

2 hours ago, Ashi Valkoinen said:

Unfortunately adding SBrick to your project will require also handling bluetooth connection

Lego Blockly supports all kind of communication type like USB (USB HID device like WeDo 1.0, USB-Serial using Virtual Com ports) and it supports BT and BLE.

Lego Blockly already supports some LPF2 (PU) BLE devices (WeDo 2.0, Boost, Technic Hub etc...)

But SBrick for me was unkown until today... 
From what I read, SBrick also has its own Hardware?  Does it have Inputs or just Outputs?
I think I saw that SBrick published its GATT communication protocol openly...  So might be fairly easy to integrate to lego blockly...  (But I do not own any SBrick hub so cannot make tests...)
And how many BLE Hub connections can blockly handle at a time, that I don't know...

I can't find any sbrick devices on marketplace in canada...

 

14 hours ago, Ashi Valkoinen said:

3. What do you think, is it possible to use PF-plug distance sensors with converter cable on old (9V) input ports?

What is a PF-plug distance sensor? you mean a WeDo 1.0 Distance sensor?  If you have the WeDo 1.0 Hub, Lego Blockly supports WeDo 1.0...

In lego Blockly you can mix Lego Interface B, WeDo 1.0, WeDo 2.0, LPF2 (PU, Boost, Technic Hub, etc) all together...

I doubt very much you can connect a WeDo 1.0 sensor to the 9v Int.B...   It would be better to get some 9V Light sensor maybe? they are not distance sensor but can detect proximity...

If you have LPF2 distance sensor, or WeDo 2.0 sensors, you can use them in Lego Blockly (WeDo 2.0, LPF2 hubs)...

Edited Tuesday at 09:05 PM by Bliss

[Bliss]

3 hours ago, Ashi Valkoinen said:

I went around 10k blocks in SBrick Pro, my station control is a really complex thing.

10 000 Blockly blocks in SBrick?

Are you sure? it is a serious load of blockly blocks

I doubt Lego Blockly can handle that much!

Do you have a peek view how your program looks like?