In fact …

Posted in 3D Printing on January 12, 2019 by asteriondaedalus

No need to bother my sister with requests for prints over 140mm cubic.

I worked out my printer is big enough to print the parts for a delta printer.

Up to 1m high if’n you want to, or you’re game … I am game.

Advertisements

Not bad for second print

Posted in 3D Printing on January 5, 2019 by asteriondaedalus

This is the elbow from a Niryo robotic arm. I seem to be stuck though, since I got the flashforge finder, since it only prints up to 140mm cubic. Still, I can get most parts built and farm out the larger parts to my sister. I will need work on a larger 3d printer once I have mastered the art. I wish I had one of these years (even decades) ago when I did Industrial Design at University.

Now I have done it

Posted in Uncategorized on January 2, 2019 by asteriondaedalus

What a lemon

Posted in Rant on November 30, 2018 by asteriondaedalus

Samsung J5 Pro.

Had it a couple of months.

Had a thick Gorilla glass added.

Had a thick carbon fibre case.

Dropped a few 10s of centimeters to land flat on screen.  So actually buffeted by both rim of case and protected by G-G.

Even with the reduced jarring the LCD failed.  Phone is kaput.

In fact no visible physical damage externally.  Just a bleeding LCD internally.

I took it back to Optus store, too bad it is “physical” damage.  They recommended going to Samsung store.  I went to Samsung store and the young guy shrugged.  He, the Samsung rep, recommended that he would not recommend the J-series phones to anyone.

The phone cost $300.  I would cost most of that to repair.

It is a $300 dollar disposable phone.

Now there is talk in Australia about the need to bring in Lemon Laws for cars.

Why stop there.  Stop telcos selling lemons as phones. 

As an Engineer I have to say that I was disgusted with how little kinetic energy was required to frag the phone.

Pegaleg

Posted in ESP8266, MQTT, node-red, OpenSprinklette on November 11, 2018 by asteriondaedalus

So, one file I had fun getting off my laptop was the source for the parser for the google calendar event titles.

The titles, as discussed previously, would be a list of sprinkler group or unit callouts.

I managed to ssh onto the laptop from my desktop to lift anything I wanted before I trashed the laptop with a clean Debian install.

While waiting for the install, I opted to tart up the parser with some sanity.

The problem for the distributed opensprinklette design is that there is no editor per se to police the entries in the google calendar event title. So, if any unwanted text is in the title, the parser running on the node-red server will drop the lot. Harsh I know, but the distributed nature of this entails some trade-offs.

So, I did add some smarts to avoid sending repeated call-outs to a sprinkler. A burst of call-outs will go out once the event title is parsed. The ESP8266 gadgets don’t mind if a single sprinkler is pummelled – it simply results in the time starting from the last received call-out – which won’t be that many milliseconds behind the first.

Still, to opt for a defensive scheme meant testing for a call-out in the return from the scan of the line before adding it to the return. Simples tick!

So, even if the user pummels the title of the event with multiple call-outs to the same sprinkler, the parsed response will only contain a single call-out.

So something like this in the google calendar title:

group1=1;group1=[1];group1=[2,2,2,4,4,4,4,1,1,1,3]

will return the following in the node-red response (prior to fully concatenating into a MQTT topic):
[
"group1/1",
"group1/2",
"group1/4",
"group1/3"
]

Crap!

Posted in Rant, The downside of Opensource on November 11, 2018 by asteriondaedalus

So, found I couldn’t run tensorflow on my laptop as the older i5 I am running is missing an instruction extension to support vectorisations.

I thought then to try to get cuda toolkit up so I could use pyCuda or Cuda accelerated pyTorch.

I got the nvidia driver installed for the GeForce GT 420M my laptop was running. Tricky since I am running Debian 9 Stretch and nvidia is anti-Debian.

Tried unsuccessfully to get pyCuda to talk to cuda toolkit.

There is no official support for the kit on Debian so I had to rely upon vain attempts by others.

I eventually found a good blurb on the problem, but my machine started blurting out app crash reports from the desktop. They kept coming through as often as I closed them. I decided to reboot.

DOH!

Laptop came up without desktop running.

A little poking round and I worked out that sddm was not running and would not run. So, no sddm, no x-windows, no desktop. Kulprit appeared to be the nvidia supplied driver for the 420M.

I tried uninstalling the nvidia driver but the driver uninstall defaults to not recovering your x-windows setup. Unfortunately, I must have twitched on the enter key so nvidia uninstall wiped itself clean, except for the x-windows config.

I poked around and found one config file that needed to have nvidia changed to nouveau BUT there was no information on the extent of mods to files required to manually backout of the nvidia driver callouts in the x-windows.

I was stuck with no desktop.

I also found I was now also sans wifi and likely few other things so I elected to rebuild the laptop (again). That is the standard approach to dealing with linux is it not. If only that was not such a drag.

Not parsed it after all

Posted in Javascript, OpenSprinklette on October 24, 2018 by asteriondaedalus

Play on words.

Now I have a reliable OPiZ server and a drawer full of quad and single EPS8266 relay setups I am moving full steam on opensprinklette again. That and I have burnt out writing papers for journals.

I finished the parser for the opensprinklette using pegjs.

As mentioned in much older posts the idea is to set sprinkler zones by adding the zone call-outs in the title for a google calendar event. When the event fires, it pings the node-red thingywhatzit and packages MQTT topics to fire relays on distributed IOT boards.

I settled on calling the quad relay boards groups rather than sectors. I am adding call-outs to single relay boards and calling them units. So, the call-outs would look something like this test string of call-outs:

group1=1;unit=9; unit = 2; group 3 = 4; unit 3;unit1; group2=[1,2]; group 3 = [3]; group4=[];group 1=[1,2,3,4]; group 2 = all

Note something important. The call-outs only turn the sprinklers on. The duration of the calendar event sets the time the sprinklers are on. Durations have a watchdog of 1hr 5min just in case server connection is broken. If you want more than 1hr watering, set two consecutive calendar events.

Don’t sweat it as there will be MQTT topics to turn on/off individual relays, groups/units, global (all groups/units). This parser is only for interpreting calendar events. I am in work fiddling with google assistant as well so calling out to google will turn sprinklers on/off outside of calendar events.

I have allowed units 0-9 and groups 1-4 (that’s 4 time quad relay on Uno shield). Actual zones per group is therefore 1-4. If’n you want more groups or units you hack into code and change numbers. The parser would need a little more work if you opted for multiple digits in your numbers. You can, of course, only have 4 relays on a quad relay board 😉

I used =;, since they don’t need shift.

I added a lazy unit definition. Just in case you forget the = when setting a unit relay on. That is, either of unit=x or unitx is legal.

A missing = will be an error in a group call.

Originally, if you wanted more than one relay fired on a quad board you would use groupx=y for each rely. You can still do that but I added the groupx=[a,b,c,d] option as well. That is you can list as many of the four relays as you like. A quirkly, I didn’t fuss with limiting the number of entries in the group array. As long as entries are between 1..4 inclusive then you simply pump out as many call-outs in the list.

Yes the you can either use groupx=y or groupx=[y] for single relay activations – smooth.

The parser generator handled groupx=[] nicely. An empty group array in the input results in no output but also no exception. It is effectively ignored.

Oh? You want what? Okay. It was simple enough to add groupx=all.

As per previous ancient posts, there will be a conversion of group or unit id to a chipid on the ESP8266 boards.

Since the calendar event will turn relays on, it hardly matters if you make multiple calls to the same relay. All call-outs go through in milliseconds, there is pulsing of relay and therefore no pulsing of waterline.

Any errors in the call-out line at all will abort and a debug message will be generated. Best that gets to node-red debug console, emailed to you so you get a prompt, or if you have an old android phone, as I have, use an SMS server to ping your phone. Most all of that is vanilla node-red.