Gunners TekZone

@Wapata Very nice! Another old LEGO Interface-B is resurrected. Arduinos still have purpose! OK, a Mega is a wee bit overkill, and a space hog... But still sexy in it's own way as a great diagnostic tool

Hello. Sorry about that... My posted pics tend to get purged as they are hosted from a free Dropbox plan, and space eventually gets used up then cleared. I do try to remove the dead links, but forgot about this one. I don't think there is a trace from that 3rd connection. I am not sure what that particular component is supposed to be... Perhaps a transistor being used as just a diode?? In my case I first tested the full serial functionality of the Interface-B by using a TTL-USB adapter to tap into Pins 22 (TxD) & 21(RxD) from the main IC 80C515. Once I confirmed that the Interface-B was otherwise functional. I connected the TTL-USB to convenient locations traced out from the main IC. I did find convenient side by side locations for such around the mid/upper left side of the board. And becasue of the whole ribbon cable rot, I simply cut all out the Serial stuff and placed the USB/TTL adapter in place of the DE-9 socket. I did have to move (replace) the large cap to make space. I hope this helps.

I don't do the IoT thing much. I prefer to keep my home networking, as limited as it is, entirely away from the cloud. And since I don't get out much, that works just fine for me My current experiment at least keeps my MQTT credentials entirely mine, no need to share with a web based application.

Well, I had a thought (it happens once in awhile )... How to link two different Interface-Bs that are running under completely different processes? So, it turns out that a simple 9v style cable between two interface-Bs, one on an output of the 1st and the other end on an input the 2nd just works... Even if the only other thing they share is the power grid. Which makes sense once I thought of it... One is essentially "closing the contact" of the two wires in the cable, while the other is seeing that as a simple switch. So just for giggles, I have Bliss's blocky program taking a button press from my LegoB2, processing it as an output on LegoB3 which is wired up to my 3rd Interface-B (formerly LegoB1) running independently off it's usual ESP32, and processing my Node-Red (on an Raspberry Pi) running (amongst other processes) a MQTT lamp control flow. Thus in a simple roundabout way, I can have Blocky running logic to control an entirely separate MQTT setup. This is what I call FUN in my foggy moments

Hmm, yes, I just might have the parts after all ... I got the same Serial to TTL 3 pack as you probably did, and I am sure I have an HC-05 or similar from back when I messed around with that more often. That said, I'll leave the Multi-Wireless-Serial stuff to whomever really wants it. Most of my testing setup and connections are already cramped and a nuge away from disconnecting themselves as is

Ahhh... I see how those One Shot blocks work now. Thanks! To keep with the multi-interface testing, I setup my ON switch on LegoB1, the OFF on LegoB3 and the target outputs on LegoB2. Working just fine! And that variable swap seems to work nicely as well! Perhaps (if easy) just make that variable setup a "built in" function block, so one can use it or not as they chose? I is confused ... again... So, this is running the webpage (WiFi) and controlling the Interface-B (BT) solely from a phone/tablet? Well after the whole Rube Goldberg TTL/BT/Serial setup of course. That was some nice jerry-rigging! Not sure how that would work with multiple interfaces?? Alas, I don't believe I have enough bits-n-bobs to set that up for testing. Hmm... Personally, I would just have the same physical PC/Tablet with wired USB and simply VNC to that with a phone. But even that seems unnecessary as your current application is all about the programming of, not the "control" of the program... Not unless you are planning on adding GUI based control/display options as does Control Lab?... Just with Blocks instead of LOGO.

Ah, yes... Something like that, but in the background code. But again... Please don't stress about it, I'm not I am not your ideal target base. I tend to run out of steam too soon, thus rarely get far in making my own big projects before I have to set them aside... And promptly forget much of what I learned. But I do like smaller ones, like testing for others... So this is that!

Hah... This old dog don't like new training for something he isn't likely to use outside of testing... But who knows... "I'm a man, but I can change, if I have to, I guess". As for the output labeling, again not a big concern if others don't care, but I am very use to the alphanumeric distinctions between Interface OUTPUTS and INPUTS. The logic you describe could probably accounted for in the back end, as an "A" label for an Output will always == 1, as will a 1 == "A". HEXADECIMAL does it... But then that is confusion all of its own. However, that is added complexity for the program, while us "meatbags" are somewhat more adaptable... So I will survive That said... I do not understand what these do? And your example doesn't even seem use them?? But that falls under "learning blocky" and I might forget how to feed myself if I cram too much "new" through the brainfog

But in my slapped together test, once activated the port on B3 stays ON... EDIT: Well, that was before my 2nd IF block was added... With which it will turn OFF, if I time it just right Normally I would use something like an IF/THEN/ELSE, but I don't currently understand that equivalent in Blocks. 2nd EDIT: This was just a whimsical test to see what happens to a running program if the STOP button on the device with the button was pressed, then later released.... Turns out it just keeps on keeping on, as expected

Yes, this seems to work as described. I tested by both disconnecting the Serial end (Disconnecting the Interface-B but leaving USB/Serial adapter "visible" to the O/S) and by just disconnecting the Interface-B from the serial connection. Same results... Program stops and will not run until missing device is physically connected and made active. It did retain the prior device name/number. As an aside... I suggest changing OUTPUT labeling from numerical to the A, B,C... H as indicated on the device (and referenced in Control Lab). Also... As I previously mentions, I generally don't do Block type programming, mainly as they seem to keep changing how they are interpreted, depending on the program implementing it... whereas Python teds to stay a bit more universal (within versions at least). To clarify, I am confused here... There seems to be a way to check for an ON but not an OFF on an Input port? Or am I just misunderstanding the logic flow? Highly probable as I am only on 1st coffee...

OK... That "issue" (one of my interface's Serial connection is very loose) was really the only issue I ran into with my initial and simplistic test, so good to know that it is expected behaviour. Microsoft Surface 3 Pro running Windows 10 Pro 64bit.

OK, I finally jury rigged a 3 device multi-Interface-B setup. I rarely use block type programming but it is simple enough, so I successfully toggled ports one ON and OFF, in alternating fashion, on LegoB2 & B3 with each button press on LegoB1. I have noticed that if one of the interfaces is temporarily disabled (due to loose serial connection) then everything stops. Stopping and restarting the sketch will not work. It requires disconnecting/reconnecting ALL Interfaces in order to get back to operational condition. And in the case of one of my Interface-Bs, whenever there is a device issue, even if it is a different one, it throws a BufferOverrunError: And I have to physically disconnect and reconnect it on the USB hub, else it usually connects as the next device number up (AKA LegoB4 when it is normally B3). But as that particular Interface-B is one that I surgically replaced it's internal Serial circuitry with an internal TTL/USB device... who knows... it might be a bit quirky? I'll have to swap them around and see if this issue follows the device or stays with the last one connected. Anyhow, that is all I can work on tonight. And @Bliss I will probably DM you with further troubleshooting posts for the time being, and limit my public posts re: this testing, for more relevant announcements.

Heh... So sorry... I tried, but was hampered by lack of energy/focus... And as it turned out, lack of available USB ports on my already overloaded daily driver laptop. But I am trying to maneuver some projects around to get one of my "dedicated to LEGO" Surface tablets (and appropriate USB hub) setup with my three Interface-Bs... All in my main "living/functioning" space. EDIT: Done... And I posted 1st results in the other topic you linked above.

Ya... I was silly and purchased a big batch of Mindstorms LEGO about 3-4 years ago. Parts, books, software, the RCX Bricks, a couple of blue scout bricks, some trans-blue lidded thing with a couple of built in motors, and a wider old-grey model also with a couple of built in motors. But I never really found a use for them. But getting a bunch of them to act under remote control from a Python controler sounds like fun. I did experiment a bit doing such, using my bench RCX and the code that Bliss had made about a year ago.

I don't know what to say or do... The link is valid as far as I can tell. Nothing spectacular anyhow... Just a box of 11 LEGO RCX bricks, and a few other bits and bobs. I have a 12th that is "thinner" as in no battery box, just a plate built base and with wired connections for both power and optional external audio. It just sits on my desk for experimenting with. I'd post a pic... But...

Oh, you are referring to my pictures? Is that what you meant before? I was somehow thinking that was relating to program image links of Bliss's stuff that I might have reposted. I don't tend to leave everything I post sitting there forever. I ramble and most is not relevant to the topic. And sometimes I overshare so purge happens . However, as far as I am aware, all my recent photos posted here are still active public links (I use the free dropbox, so older stuff will eventually be removed due limited space... But I do try to clean up the dead links in those cases). And if the link was dead that would affect me as well, but I can still see them.

Sign me up, again... I can pull in three (3) Interface-B's and... well... perhaps scrounge up an RCX or two

Well, I was a trigger pull away from an OG 9767 (partially because it would have tickled my senses using an original $$$$$ LEGO relic in a $50 clone APCO IIe) But thank heavens divine intervention triggered some common sense, and my bank account can stop acting like I am murdering it (for now at least ). The Blocky option is bat crap crazy priced for what it is, so not even going there. And alas... I simply haven't been having any results trying to figure out how to use those two random Apple I/O boards I have. Turns out the smaller one was for a braille "display" and the larger was a part of a "general purpose?" external interface setup for "whatever". But between my inexperience with all things Apple, and AI being mostly useless with assisting in my attempts to communicate to them. I am setting aside the smaller for future experiments, and stealing the 6522s from the larger one.

Yup... I can be totally clueless when it comes to navigating GitHub. Thanks for the links Ah... good... I am not (totaly) clueless after all... I was just searching in the wrong year, last year (for the LEGO stuffs... I wasn't searching by name). And since we are sharing... https://github.com/Gun-neR/MQTT-Example-for-RPi-BuildHat No, it has nothing to do with the Interface-B. But at least it is LEGO...ish

Actually, I am not sure he has a GitHub repository... I barely do. But all the links are already here to download (beginning of topic)... Why not save him the trouble and copy it over yourself? (with credit)

I am using @Bliss's code (also in the link I provided above). I have no code of my own in this... That's part of the reason it took me a moment to realise why it seems so confusing. I was getting my memory recall mixed up between how I got this Int-B/ESP32 combo going, compared to a Raspberry Pi LEGO-Hat that I also have running as part of my MQTT test setup.

Ahhh... now I got it... again. This was a "Generic" sketch that covered all the Interface-B inputs and outputs and basic sensors. It is using Bliss's V1 version which uses uasyncio. It has an imported micropython MQTT-Client, and all it does is send a "1" on the PUB channel, when switch is pressed (or whatever signals are relevant for rotation and temp, etc.) and listens for a "0/1" for the outputs (and "1 through 8 " for whatever output power is specified) at SUB reception . All the "heavy lifting" code for this particular "relay switch" is in my Node-Red server. That is where I handle the toggle code and SUB/PUB protocols for this one, as well as other testing I was doing. I still have settings there to read rotation and temp sensors as well as control a bunch of the outputs that I had motors and other lamps on... Back when I was more actively messing around with this. That is what happens when you don't play ALL your toys more often You have to post stuff on forums... In my case, not so much for others, but so I can find out how I did whatever I did at that time when the brainfog wasn't as heavy

UPDATE: March 1, 2026... And my In-B/ESP32/MQTT hookup is still working, easily for many months at a time in between power/reset. I have seen some interested parties in other forums, working on their own ways of running the Interface-B via Python, and I have referred them to this topic. Unfortunately... I seem to have forgotten how I even did this (as in how I programmed the MQTT sketch) "Ahh, brain fog, let me give you a piece of my min... Hmm, now where was I going with that??" I can log into the ESP... but none of the files seem to make sense to what I know is happening... The switch on input 1 sends an MQTT SUB command to toggle an AC Relay and the lamp on output A responds to any incoming PUB command to show the state of said external AC Relay. This Int-B is just one of a total of 5 totally different button/indicator systems , including the AC relay itself, and they all update whatever display method they use based on the actions of the others. Oh well... at least it remembers what to do and how to do it.

Well... A bit of an update on my "Can I use this smaller random board for LEGO I/O in lew of a proper 9767" saga. Recently I finally had the focus to finish mapping out the pinouts on the smaller board: Dropbox link of PDF I then tried to get AI to help me toggle some LED's with this board (as I am sooo No0b concerning Apple IIe stuff)... Either the AI is braindead, or I am?... But it keeps telling me that the port sockets where numbered backwards (7-1 right to left). And while trying to determine why nothing was woking, It wanted to confirm I was probing the correct Pin for DEV SEL (Pin 41) on whatever socket I was testing... as it was telling me it was on the component side of the board (NO, it is not). Needless to say "we" didn't get far, and never toggled any LED's... Just tweaked my patience a bit Time to do more Googling, and I did find a YT video of some guy that designed a great Apple IIe Signal Diagnostics Board (that I could use to nail down the signals and programming bits). Alas, there doesn't appear to be any follow up video or info where to get the kit? Oh well... This topic is on the Interface-A (which is my ultimate goal toward controlling an such via my APCO IIe clone, and a board I either mod or build myself). Thus the trials and errors and errors, and errors... But short of purchasing a genuine 9767 (and only because it seemed cool at the time, but that thought fizzled out... And my wallet is thanking me ) I currently refuse to spend big $$ on a reproduction board like Blocko. It just seems too much for what it is and I am simply not that desperate to run LEGO on the Apple. To me, this is about learning the workings design and building process, with what I have on hand, more so than just slapping existing parts in. BTW, the larger of the two boards was intended to become a donor for the 6522A IC's, to eventually make my own repo of a 9767 (still in the plans). But now I might switch my testing to it and see if it reacts any better with AI assistance?? I'll keep on plugging at it. BTW, I didn't really need or plan on getting another one, but I just found and ordered my 2nd Interface-A... Original box (Cool, but just going to sit on a shelf, empty, alongside my 1st one) with PSU and OG cable for $104 CAD SHIPPED! ... I simply couldn't ignore that price! I think I might dedicate it for my Sharp PC-G850VS I/O to Int-A testing... While I give the Apple a timeout

Hah, small world. Not too long ago, I actually tried to buy this one... But got a message "The seller isn't accepting bids or offers from you" instead I have no idea why, I don't recognise the seller as someone I might have dealt with before... Might be a glitch as I do see the PayPal link try to show briefly I tried messaging, but never got a reply. Oh, well... I need to actually get my Apple and/or Pocket PC connection to my existing Interface-A, before I start worrying too much about finding another affordable one.