No GRBLs harmed …

… certainly no cardboard tubes used in the production of this blog entry.

As mentioned elsewhere, I did centre on the board I would build into my Bear clone. BUT!

There’s a but …

BUT! I did want a low end hack board, to drive steppers and build little experimental rigs. So, I marvelled when I came across a project called Grbl_Esp32. Neat!

Now, there’s options for buying boards, but it occurred that I might sneak Grbl_Esp32 onto a “Wemos D1 R32” clone (for real “Wemos”, apparently now DIYMORE go here).

These nifty Wemos D1 R32 boards are an upgrade from the Wemos D1 R2, the board type that I built the first generation of Opensprinklette upon. The Wemos D1 R2 being ESP8266 based, though still ample for managing the task at hand.

But, GRBL on a Wemos D1 R32 seems doable if you add a shield such as the CNC Shield V3.

So a MoBo for AUS$4.68 and shield for AUS$6.72 … hmmm 8+2 is 10 … carry the 1, etc. … iterating … AUS$11.40!!

Outside now of my occasional use of both OpenSCAD and FreeCAD, I have also downloaded a few further CAM apps to begin famil, including:

• GRBL Controller (alterative Universal GRGL Sender or UGS)
• CAMotics
• OpenPnP
• DeepNest
• FlatCAM

GRBL Controller was very happy talking the the Wemos D1 R32, which was running Grbl_Esp32 in test mode. I just need wait on the CNC shield, to start working on configuring Grbl_Esp32 to talk to the shield. Whether I need cut tracks etc. TBD. The pins of the DRV8825 I selected, to pop into the shield, read as 3.3V. Looks very, very doable.

Too much fun to be had!

Oh! Oh! Oh! Have a look at SolveSpace.

Slowed up again.

All I am after is 5 molex mini USB sockets, am I nit picking?

5 from element14 is AUS$28, $11 for the widgets, $15 for postage and then GST on top, but a week for delivery. Going then for AUS$5.60 a widget.

Looking to Aliexpress it’s $17 for 10 widgets, but upwards of 50 days delivery. Otherwise AUS$1.70 a widget.

So, another long wait, as I am going through Aliexpress.

Un-Foobarred Phubar 4

So, a bit of fiddling but I sorted what I had done wrong with the EEPROM. The resistor arrays problem was, because I had went to snapEDA to get symbols for a specific array, but it did not come with a 3D model. It turned out you just use a (so-called) R_Array_Convex_4x1206.

I just now need sort the crystal and the LED and then do a quadruple check of the wiring.

Foobar! Dosh goddamit!

Whoops!

I fidgeted with changing the parts around to get the board smaller. Had a great idea! I would put the regulator on the back!

What I found out is there are some quirks with doing this as I swapped sides on pads etc but missed the flag to actually put the component on the other side.

Not to mention, I seem not to have assigned packages to U2 nor the two quad resistor arrays. Otherwise, looks close to good enough to get a small batch made and then start fiddling with programming it. The board can evolve once a code base is up.

So, with a little bit of fiddling, noting there is a top/bottom flag in the component wizard, and voila! Just need to sort some package libraries for the last items.

I have a box of assorted SMD crystals coming from Aliexpress, so one last touch and then to the pcb manufacturer.

Board dimensions are 36mm by 40mm. Not bad since it’s got a 8-core 32 bit MCU running on it.

Phubar resurrected!

So, way back there was a hack using a Parallax Propeller chip called Phubar.

Ostensibly a gyro for RC helicopters, but I thought it might be a good little fun hack project for small quadcopter.

Now its some distance from the ELEV-8, but what if you wanted a small hack for … hacking? Why not.

So, it had always occurred to me by beefing up the board by adding an MPU-9150.

The thing that made this task a dream was actually a discovery that there is a separate auto-router available (outside of KiCAD), that can suck in Specctra DSN (exportable from KiCAD). There are various red-herrings out there as to how to install a tool called Freerouting. Ignore them and go to this link.

So, a little dabbling in KiCAD was in order. Starting with the schematic for Phubar 3, I scratched out a Phubar 4, with MPU-9150 (see U3 in image below). This is the first pass hack to work out the tool interoperability. So this is one run with the auto-router. Pretty neat! But you can’t just dump chips and expect the thing to solve your problems. You need to input the design and generate a netlist. When the PCB is auto-populated you need take note of the messages the netlist is visually given you. Meaning, you need try “unwind” anywhere the netlist is “crossing the streams” in the tangled “rat’s nest”. This will take moving parts around and rotating them to try and reduce any tangled “rat’s nest”. Once you have untangled the “rat’s nest” displayed over the PCB, then export it for auto-routing.

J1, the propplug port, is drawn off the board, a whoops which needs to be fixed. J12 is to provide a separate serial port from the programming port. J11 is the I2C aux from the MPU-9150, to allow chaining out the I2C port. J10 is the original extra port. Still playing with how many to add or take away.

The aim will be to now cramp it up a tad more, replace the original crystal with a SMD variant and also downsize connections and maybe sneak a circuit for a simple camera and camera Tx — or not.

I might also just turn the optional external port J10 into a GPS port. There was promise of this from Phubar 3 but the code based it apparently turned up in is nowhere really to be found. Ah well, some more hacking to be had.

Nit Picky

So, I did actually change my mind on the ATMEGA328P based paste dispenser from really a PnP tool based:

To an interpretation of the hand held same:

Which is still ATMEGA328P based, being an interpretation of:

Which was PICAXE M14 microcontroller based.

Note again, the second option is for a hand paste dispenser. Do not write off the first option as it is perfect for use in your DIY PnP machine (does everything need be a NEMA17?). Or! Maybe it does:

However, to actually progress through the process, I need a dispenser to build the inaugural ATMEGA328P dispenser.

Options are either:

Or:

So, the order of build will be:

1. Non-automated hand held paste dispenser.
2. Automated hand held paste dispenser.
3. Automated PnP paste dispenser.
4. Non-CNC and therefore manual PnP machine (to incorporate 3).
5. Assemble the 5 ESP32 Wifi Robot boards I ordered from OSHPark, using my new manual PnP machine.

I have recently received the last delivery of parts for the ESP32 Wifi Robot boards. I am expecting the first delivery of frame bits for the PnP, with the hardware also ordered. I have yet to order the pneumatic bits.

So, pressure then to put my Flashforge Finder back together as I have to print the 3D parts for both the PnP and reprint the parts for the Bear build, given I did not calibrate my Finder first and also a change in the design in the Bear designs, as well as I have changed my mind about the extruder and the Brains. So the frame can finally get dusted off.

I otherwise have 5 each of the first and second ATMEGA328P based boards solder paste boards. Five is the minimum number of boards from PCBWay.

I have ordered parts to build all 5 of the hand (not PnP) version. I will try to sell 4 on ebay, in an attempt to pay off the the expenses. I am yet to buy parts for the PnP based version, but I’ll do the same. Probably will also do the same with a couple of the ESP32 Wifi boards.

Won’t be making me a millionaire but might help soften the blow of the hobby.

Bad, bad, bad, bad, …

… bad, bad, bad Aliexpress vendor.

Not just for taking sooooo long to deliver the poor chap’s widget, but not supplying manuals etc. is bad form. No description of pins, naught.

A quick Net search suggests the device is a doppler widget, going by the visual appearance, with cleaver direction function, by BB & Themo-Technik.

So that also means the vendor is false advertising the device as providing distance measurement. Tich, tich, tich.

Ali The Crapper Award

UPDATE!

The vendor link is dead, long live the vendor link.

Revisionism Extraordinaire

There are some extraordinary examples of revisionist interpretations of history around software development, entirely missing the impetus set by the criminality behind software piracy and that era which rolled with the mantra that “software was art” and therefore should be “free”. Really just trying to rationalise the criminality.

That era really making it clear that the legal instrument was so impotent in dealing with the problem, the “software is art” movement thus becoming a pseudo-revolution as the companies went under or gave up the fight and tried a new “business” model.

If you look for the notion of software piracy, it still exists, but complicated by the problem of whether free software is being used within the bounds of the licence it is offered against, rather than simply the idea that someone paid for the software and then criminally gave copies to others. So, this is a conundrum because the criminality of the software pirates, when sharing commercial software, is and always was a licence issue. So if the license issue has not gone away then why was there ever a justification for sharing?

It was never really apparent that art was free by the way. Paintings aren’t. Music isn’t. Even better, today there is discussions around the greenness of crypto art, which uses block-chain to manage uniqueness, so the digital artwork can only be owned once and occasionally selling for millions of dollars.

We see then open source, so called free, software talked of as a billions of dollars industry. Often taking advantage of dupes who latched onto the “free” software and contributing for “free”, to get cred in some romantic picture of the world.

Although, occasionally developers of open source software now also taking positions that 1) don’t bother me with a bug unless you want to pay me to fix it of 2) provide me, the developer, a fix for the software without me, the developer, paying you for the fix.

In fact, the introverted sense much of the code is developed under has long evacuated the space of the concept of “user”. There is certainly derogatory terms the open source community has for those who use but do not contribute – you can sometimes deflect name calling by “donating”, but of course why would you, software is free right?

Now open source is touted as multi-billion dollars worth of industry, on the back of freaks working for free but who somehow need beer money, have we really go to a better place? Even the crowd funding movement is an aberration that pretends things are “free” as long as someone can support the funding of it.

Open source is perceived to be bug “free”, while at the same time open source has no care factor for security or human factors.

Is open source better at being bug “free” really? Just looking at projects on github, if you take into account of all repositories therein and not just the pitiful number of gold exemplars, in the eyes of a few, then there is a weight of buggy, unusable, unsecure software there that comfortably dispels the generalities touted by the used-car sales people leading the debate.

In fact, the monetary story is exacerbated by tools on communal sites, offering a dollar value for the “free” software, in terms of money you save by not having to buy that software, or write it yourself. Going by one tool I use regularly, noting the “cost” to develop the tool was literally calculated in terms of $Millions of resource dollars. I have to ask, since that project was not monetised, the developers are out $Millions of dollars of time and effort. It only takes 1,000 projects of that ilk to start counter-balancing the monetised $Billions of dollars of projects on Github. Noting also the $Billions of dollars of monetised projects are not then farming out a share, in the name of “art”, to the $Billions of dollars worth of non-monetised projects. That’s before you factor in what would be $Billions of dollars of lost time and effort trying and failing to overcome the “as-is” experience open source holds so high.

I can attest I have a policy if I cannot download build and run an opensource offering within a hour, I will delete it. I would really want a donation for each hour wasted.

But, spare me the revisionism. The split second you, yes you, developers get onto a piracy rant over people misusing your licenced software, you are putting yourself in the position of software developers years ago who were getting ripped off by pirates. Pirates most likely with a mindset indistinguishable from yours on the question of the manner of use of the licensed software you are borrowing from others.

The real difference between pre and post open source is that software quality was previously a property of the software. Somehow now utilitarianism has made it verboten to discuss the actual quality of offerings because the wimps writing the code cannot brook a critique, and hence the “as is” proposition. So the “quality” is, apparently, the act of contribution, however sparse in code quality, security assurance or human factors.

I must be imagining things?

So, I reported to the author of one of the ESP32 CAM “solutions” a problem I was seeing with long lags in display of camera stream using the code provided.

The author’s response was Monty Pythonesque. “It’s not dead, its sleeping”.

That is, the author claims not to have seen the problem, so it isn’t a real problem. Albeit I did note someone else had reported the problem.

I did assume the problem was the code provided was using a single task to service all clients, but I did misread the code and now understand a little more about RTOS and ESP32. The code, in fact, is running a task per server client – scary then.

There is thus a comment from the code author that there are mystery batches of clone cameras out there and that was the problem … not the code.

It’s as likely not tested fully (apart from apparently waving the camera in front of us on Youtube for 3 seconds).

Since we appear to be operating in pop culture references, you call that video evidence, THIS is video evidence. So first of two videos. Note my hand did appear in top left of the four stream client windows about 15 Mississippies into the count (I am using Mississippi as a cultural appropriation, sorry, use Warragamba or any other similar 4 syllable word). I missed it in the first video, and went for covering the camera BUT that had not shown up even after 18 <insert your 4 syllable word here>. Second video really says a lot about the lag.

So further experiments seem to suggest maybe distance (and hence -dB) might be part of the problem with allframes compiled and even trying to be gentle using VGA. I set up with t-camera more or less on top of wifi router AND disconnected my dock, using only the laptop screen, with the laptop about 2m from the wifi router. Lag halved (10-11 seconds behind instead of 20 and greater) and the display artefacts reduced noticeably.

I ended up dropping the allframes version (which spooled all clients to “ensure” that no client saw dropped frames 😉 ). I did also capture the crashing of the allframes, though the code seems resilient, since it reboots and you can refresh the browsers to restart. The crash seems to be reproducible by creating n clients and randomly closing one.

I also tried what I guess is better called the notallframes version, again using VGA, seems fine on my setup with a smidgen of lag.

Both the allframes and nonallframes versions fail to add more than 6 clients, despite the max clients apparent set to 10? I will have to scroll through the code to double check that.

There was some passing comment about use of the PSRAM being the problem (as opposed to a slow clone camera). Whether it makes sense to compile with PSRAM=false is a question. Whether you could provide sufficient buffering space with the on board RAM being the problem.

Having sorted the ESPHome version, by finding that pesky pin pullup trick, I had to note a conditional compile in the allframes relating to one specific board type requiring pullups, so I added the pullup lines for the t-camera as well. That did not seem to help nor hurt. So, happy to have an occasional poke at this over time, but not an imperative. It is interesting from the point of view of using tasks and especially the streaming aspect. Not sure this should not be ported to lua-rtos.

ESPHome no-go on TTGO T-Camera

What a pain.

This is the pinnacle of the downside of opensource and the upside at the same time.

ESPHome community, especially, with rules of what you need go through before you’re allowed to “ask” and issues “closed” but not promulgated into ESPHome baselines.

Let’s recap. Two LilyGo TTGO T-Camera v1.6.2 boards. Same ESPHome yaml file, save for device name and IP.

Problems with, lets’ call them board A and board B.

• Both board A and B came with a preinstalled app (probably this one), which runs on power up. You are supposedly to say “Hi LeXin” to it and it then starts a webservice to display the camera stream. No amount of yelling at the boards incites a response. Obviously something is running as OLED screen scrolls. No biggy, I was wanting to use ESPHome examples I had found, so I could hook the cameras into Home Assistant via ESPHome integration.
• Craft an ESPHome yaml based upon examples on the Net.
• Bombed board A, with its own version of the file. No problems apparently, initially – but don’t get cocky.
• Bombed board B, with its own version of the file. Would not start however. Would get into boot loop with the board B yaml file so bombed.
• Cut code for board B back to find if I removed the camera code, then the board fired up and “worked” – but with no camera. So, was the camera on board B fragged? Don’t rush in with an answer.
• Tried bombing board B with board A yaml file. Board B still sat in boot loop unless camera code removed, so no pesky hidden characters or problems with indenting.
• Now I told you not to get cocky. With no code changes or re-bombing, board A now, occasionally, won’t start without multiple bangs on hard reset button. Once up, seems okay. Even fires up again, after unplugging it from powered USB hub then plugging it back in (and then maybe some banging on hard reset), but don’t get cocky.
• Tried banging reset button of board B, because the log messages are eerily the same as those on board A when it struggles starting. 5 minutes of banging the reset on board B fails to get it to start.
• I had backed up the original binary running on the boards, so re-bombed them with original code. They came up again.
• Re-bombed both with ESPHome. Now I wasn’t sure which board was board A and which was board B. Both flaky. Marked up one board as board A to distinguish. Finally, after re-bombing board A a number of times, including clean, it got back to the point it would start with a number of bangs on the hardware reset.
• Gave up. Assumed as long as I could get it started, board A would do as a video door bell, with IR trigger to tell us when someone was there and maybe not inclined to press the button on the gate. So put the project aside until I found the hour or so to run into Jaycar to get a case.
• Come back a week or so later and FRACK! The OLED board on board A not working. Were it software? Were it hardware? I really only placed it into a box of parts for safe keeping. It seemed to connect to HA. The PIR, button, status and wifi signal all working. Opted to go with it and just not bother with the OLED display. But it bugged me.
• To add insult to injury I had found a bunch of resources, including what appeared code for the t-camera series but not HA ready. Regardless, I bombed board B with the native t-camera code and voila! The pesky board ran, with camera streaming, confirming the camera was not fragged. But, FRACK! The OLED on board A did not come up. So, looks like a hardware not software frag on board A somehow?
• I opted to then drop the ESPHome code and use the t-camera code, since it was standard mjpeg stream, with control options mind you, with:

• Another problem popped up, the example code for an mjpeg camera in Home Assistant, when stashed in configuration.yaml, did not create either a camera entity nor device to use. There was definitely a stream, as you could hook it into a chrome web page and therefore a picture entity. There were no errors reported when HA was started, so no evidence why a camera was not created.
• Yet another problem, the t-camera example was for a single streaming client and I wanted the cameras to come up wherever the HA HMI was brought up. Solution, I found code that provided up to 10 streaming clients, goodnuff for my needs, thanks arkhipenko! Just needed to mod the pins descriptions to include the LilyGO cameras (based on the t-camera pin definitions by lewisxhe).
• Note, while the allframes option sounds great, there is a substantial lag in the displays because of the spooling. So, great for a dvr set up, but not intuitive for a video door bell. Also wik, note the code defaults to max resolution for the camera, which again causes lag. I opted to set for VGA and used esp32-cam-rtos instead of esp32-cam-rtos-allframes. Might be fixed with a task per client, noting the software only creates a single task to handle all clients. I am going to poke at that in the background, since all the hard work has been done otherwise.
• Notice there are quite a number of boards arkhipenko had included, now with my T-Camera mods (only tested for my v1.6.2 mind you). I am looking at at least adding the OLED for the t-camera and, of course, MQTT and PIR etc.
• Oh yeah, the code from arkhipenko works on both board A and board B. So, it is definitely ESPHome that is struggling either on the t-camera or on ESP32 boards generally.

Now if all that ain’t bad enough. The boards, when loaded with ESPHome, seemed to be happiest when plugged into a powered USB hub. When plugged into a WEMOS single 18650 battery shield, they would not work or at least would not start – no matter how many times I banged on the hard reset. That is, neither of the boards would run off battery. So, I thought this was either an amperage or a noise thing. It was strange as I tested with multimeter and seemed fine. Sniffed with my DSO but noise was not an apparent problem.

The final insult then was, when loaded with original app or either the t-camera or rtos apps, both boards (A and B) ran no problem off the WEMOS battery shield. They just refused to start up or connect to wifi while running ESPHome unless they were hung off the powered USB hub. It’s inexplicable but was it worth my time to track down.

Ultimately, it turns out I mis-read the issue at ESPHome issues being “closed” meaning the fix had been incorporated into the baseline. It isn’t! You still need to dig out this nugget and manually hack your main.cpp code, avoiding the autogenerated sections. Now for whatever reason, not setting pins x=12..15 at start, with pinMode(x, INPUT_PULLUP) leads to both problems with boot loops, often aggravated if the camera code is included AND, it appears, the problem with t-camera not running or booting on battery (for whatever dang blasted reason). With pullups on those pins even board B now comes up with camera and runs off battery, despite having the ESPHome code running. There is thus a question around EMI in the design of the t-camera v1.6.2 that, luckily, can be fixed with pulling a few pins up.

Make sure then that somewhere in your autogenerate main.cpp code reads (safe to hack, lost when you clean):

void setup() {
    pinMode(12, INPUT_PULLUP);
    pinMode(13, INPUT_PULLUP);
    pinMode(14, INPUT_PULLUP);
    pinMode(15, INPUT_PULLUP);
    // ===== DO NOT EDIT ANYTHING BELOW THIS LINE =====
    // ========== AUTO GENERATED CODE BEGIN ===========

From accounts I can put together, this problem is with a few ESP32 CAM boards and was dealt with in the code by lewisxhe, which is actually where the hack for ESPHome comes from. The hack probably needs to go into ESPHome, so there is a bug report to open the problem again to have it closed in the ESPHome baseline.

Re-bombed to ESPHome, with the hack in both devices main.cpp. Fingers crossed.

So, here is the test setup running.