Courier just dropped off the servos and controller 🙃
Just love these guys slogan... they tempting me way too easily  🤣

Also just in time, I finished programming the servos this morning.

Servos code running nicely.

 

Edited December 29, 20232 yr by WannabeSolarSparky

Setup a small test rig on my desk to check the coding for the servo's.
Works as expected, just had to reverse the servo directions 🙃

Fast work!  🙂

How does it sound? 🙉

Meanwhile...

😭

6 minutes ago, HedgeSlammer said:

How does it sound? 🙉

Well it's inside a small cardboard box so it amplifies the sound, but.... it is still pretty quiet.
On my way to go find some of that plastic board to test on, but I am pretty confident the sound will be ok on there too.
The servos move in very tiny increments and only if the values change by more than 5 degrees so overall I think it will be good 🤞
Will have to see once all the servos are hooked up.

11 minutes ago, HedgeSlammer said:

Meanwhile...

Nice, I see you going to give those led strips a go

I will also share my code once I have everything working...

On 2023/12/24 at 9:23 PM, HedgeSlammer said:

The 'arms' - about 150mm long.  Might need to be a couple of mm wider/deeper to accommodate the 74HC595 chips at the back.

 

The whole display will be around 500mm x 500mm...

Not sure about the 'inverter' thing in the middle... might just do a model of the Victron Multiplus II, and reproduce the status LEDs from the front panel.

I hope Santa brings me some more hot glue sticks. 😁

Not sure what Inverter you're using but here's a Vector image you may want use. The PDF format has two pages first page is one you can use to 3-D Print. There's a type of material we use in printing called "Forex" it's a lot more sturdier (3mm) and a lot more robust than Corex over the course of time... for your consideration. 😁

System Display.pdf

Edited December 29, 20232 yr by Moffat

Cheers for that, Moffat. 🙂

We use a Victron Multiplus II here, so I'm roughly modelling that with white PETG and lighting it up from inside...

There should still be room to get the ESP32 in there, too - if I go steady with the hot glue, that is. 😁

Maybe I’m late but, as a suggestion for the led SOC meter, I used LM3915 in the past for vumeter bars. It is an integrated dot bar driver and it just needs a few components around to work.

It has an analogue voltage input that can be fed from an analogue SOC output signal. One single IC can drive 10 led’s

2 hours ago, HedgeSlammer said:

Cheers for that, Moffat. 🙂

We use a Victron Multiplus II here, so I'm roughly modelling that with white PETG and lighting it up from inside...

There should still be room to get the ESP32 in there, too - if I go steady with the hot glue, that is. 😁

Happy days with the Blue Machine... find artwork for the MultiPlus-II here which you may print on vinyl for your use if you can.

MultiPlus-II vector.pdf

2 hours ago, Mauritius B said:

LM3915... It has an analogue voltage input that can be fed from an analogue SOC output signal. One single IC can drive 10 led’s

That's an interesting idea...  +/-25V input, and they can be cascaded? There's probably even still one or two lurking at the back of a component drawer around here somewhere. 🤔

51 minutes ago, Moffat said:

Happy days with the Blue Machine...

I was considering faithfully reproducing the Multiplus status LEDs, but realised that they're not particularly informative or useful.  Using the whole 'inverter' on the new panel as a 12 segment indication of inverter load will be much more useful.  I'm thinking of having blue up to nearly the limit, then the Victron trademark 'orange stripe', then everything turning an ominous red when the inverter limit is exceeded and we're drawing grid power.

Anyway... I made a pylon (or rather, the front of it):

It sits on top of another one that is slightly thicker, but also has a 0.5mm backing 'membrane' printed the size and shape of the middle bit (i.e. without the arms) to diffuse the (6) LEDs.  The lower bit looks wrong (it would be unstable), but I had to make room for the light pipe thingy to attach in at the bottom.  The printer's just chugging one of those out now. 🙂

Deciding on the style look and feel is more complicated than the coding 🤣
Leaning towards a car dashboard type feel with a nice chrome frame.

I have also changed the size to A2, my original idea with 100cmX70cm was just way too big.

 

11 hours ago, WannabeSolarSparky said:

Deciding on the style look and feel is more complicated than the coding 🤣
Leaning towards a car dashboard type feel with a nice chrome frame.

I have also changed the size to A2, my original idea with 100cmX70cm was just way too big.

 

This is great work. Is the Solar PV in text mirrored for a reason 😀😀🤔

4 minutes ago, Scorp007 said:

Is the Solar PV in text mirrored for a reason 😀😀🤔

This is just my scribbling so I can figure out a nice layout, will be doing all new hi res images with the correct scales and numbering before taking it to the printers 🙃

 

These VU type analog meters are also a nice retro type idea for the meters. Pretty much same price as servos and can use the same coding tweaked a bit.

https://youtu.be/hsVi-xJLwrc?si=soUyAg_yyeNHbHyI

 

54 minutes ago, WannabeSolarSparky said:

This is just my scribbling so I can figure out a nice layout, will be doing all new hi res images with the correct scales and numbering before taking it to the printers 🙃

 

For the last day of 2023. Tomorrow you can flip it 😜

Ready to do a test print at full scale ( A1 - 59.4 x 84.1 cm ). If all goes well then I can fine tune the dials, visuals and add the ticks

Next I can start looking at the design of the needles, shape and colours.

Once completed the colours will be inverted to white on Dark Grey Background and printed on white vinyl onto an art box frame with a chrome frame edging.
 

Coding 90% completed
Ticks added, now ready for second  test print which will be used to layout the final board, led's, servo's, buttons and brightness pots.

 

Looking good! 😎

My LEDs are apparently in the UK now... "5 Jan 2024: Customs Clearance-London Heathrow, Scanned-Scanned At Dispatch Hub".

I did get a string of 30 (30 per metre) WS2812b to test with in the meantime.
All the 3D printing is done and (like you) I'm 90% on the coding.  I'll have to fiddle with the timing/speed of the flows some more once I have the LEDs connected and have removed all the 'Serial.print' cruft.

How are you regulating the speed of your 'flows', BTW?  Simple timers with a variable interval?

I decided to make things extra complicated for myself by making the flow LEDs fade in and out as they moved along, so for lower speeds (<50%) I'm using a varying non-blocking delay (interval) between each of the (255) 'brightness steps'.  With an interval of zero, the flow isn't fast enough, so for >=50%, I increase the number of 'brightness steps' taken in each iteration.

Theoretically, this approach should make the flow speed double between ~49% and 50% (when 'brightness +/-1' becomes 'brightness +/-2'), but curiously it doesn't seem to.🤔

I've shot myself in the foot, there, as I can't now regulate the 'global' brightness of it without all the timings/speed changing.  I could do a 'constrain', I suppose - or a 'map' - to limit maximum brightness. 

An aspect I hadn't anticipated was the need to explicitly turn LEDs 'off', since they each finish their innings at zero brightness.  Normally, I guess you'd set them all 'black' after each 'Fastleds.show()', but this made everything flicker and takes too long, so I just turn off the one that preceded the currently dimming one, which appears to work.

Also, did you get away without using a level shifter (to bring the ESP32 LED data outputs up to 5v)?  I'm getting mixed results, but will probably use it - especially if I can just power it (3.3v side) from a GPIO pin set high. 

53 minutes ago, HedgeSlammer said:

My LEDs are apparently in the UK now... "5 Jan 2024: Customs Clearance-London Heathrow, Scanned-Scanned At Dispatch Hub".

Nice they should be with you soon then

53 minutes ago, HedgeSlammer said:

How are you regulating the speed of your 'flows', BTW?  Simple timers with a variable interval?

int FlowSensorValue = analogRead(FlowSensorSpeed_Pin); // A0 pin 36
  flowSpeed = map(FlowSensorValue, 0, 1023, 1, 50);
int LED_BsensorValue = analogRead(Brightness_Pin); // A3 pin 39
  BRIGHTNESS = map(LED_BsensorValue, 0, 1023, 1, 50);

Simply using two potentiometers and mapping them in to control the brightness and flow speeds.
Currently the flow speeds are simple delays.
Once I have done the physical mockup and know the exact number of LED's for each segment then I will recode everything into frames and palettes and eliminate all the delay code bits.
I am using the cylon code which gives a nice trail effect to the flows.

53 minutes ago, HedgeSlammer said:

Also, did you get away without using a level shifter (to bring the ESP32 LED data outputs up to 5v)? 

LED strip + connected to direct esp32 5v VIN
LED strip data connected direct to pin 23 - no external level shifter required as the data line is independent of the + line.
The 1st led acts as the levelshifter quite effectively. If your 1st led is far away from the eps32 pin then you may need a level shifter.
The esp32 puts out more than enough power to drive the data line. Set the max amps to 500ma and max brightness to 50. With those settings I have tested the full strip of 300 led's without any external power and experienced no colour fading or bad data.

I am using the Lolin32 WROOM, it's has pretty robust power handling stock standard.
I am currently driving all the led's and 10 servo's without external power and have had zero issues with the servo's or the led's colours and sequences.

On the final board I will however add an external 5v PS to drive the led's and servo's

Edited January 7, 20242 yr by WannabeSolarSparky

Cheers for that. 🙂

From the WS2812/13 datasheets, they suggest that the data level needs to be 0.7 x the supply voltage, which would mean 3.5v at 5v supply - a tad higher than the ~3.3v the ESP delivers.  Reading around, sometimes you can get away with it, sometimes not.  Depends on the particular LEDs.  One neat trick I came across was to split off the supply to the first LED and stick a small silicone diode inline there, which drops the supply voltage by 0.7v, meaning 4.3v x 0.7, so 3v data level, then the second LED takes it back up from there for the rest of the string.  It does mean that the first LED will be a bit dimmer, though.

I'll stick with the level shifter, as I already have some, it fits in there nicely and I won't have to experiment too much when the LEDs finally arrive.

I started with the 'cylon' code, but it doesn't give me that 'ramping up' or 'fade in' effect for the leading LED.  The 'blur' thing looked promising, but a bit clunky at lower speeds.  I've gone for one 'active' LED on, then the one in front of it is ramping up as the one behind is ramping down by the same amount and the one behind that is turned off.  Probably completely unnecessary, but I won't let that stop me! 😆

7 minutes ago, HedgeSlammer said:

I started with the 'cylon' code, but it doesn't give me that 'ramping up' or 'fade in' effect for the leading LED.  The 'blur' thing looked promising, but a bit clunky at lower speeds.  I've gone for one 'active' LED on, then the one in front of it is ramping up as the one behind is ramping down by the same amount and the one behind that is turned off.  Probably completely unnecessary, but I won't let that stop me! 😆

looking good there

Here's the whole thing so far...

I might have to re-do the sun, though.  It's supposed to be sized so that the 60-LED-per-metre strip lines up with the 'rays' inside, but I suspect it won't and needs to be about 15mm bigger diameter...  I tried it with the 30-per-metre, expecting it to be lining up with every other ray, but it's miles out. 😢

Still, what's not to like about a bigger sun?  Making the 'rays' a bit bigger would certainly print a lot better, too. 🙂

9 hours ago, HedgeSlammer said:

I'll have to fiddle with the timing/speed of the flows some more once I have the LEDs connected and have removed all the 'Serial.print' cruft.

 

This is how I handle the serial print output

Add to the top with all your other defines.

#define DEBUG 1    // SET TO 0 TO Disable serial debugging info or 1 to show serial debugging info
#if DEBUG
#define D_SerialBegin(...) Serial.begin(__VA_ARGS__);
#define D_print(...)       Serial.print(__VA_ARGS__);
#define D_write(...)       Serial.write(__VA_ARGS__);
#define D_println(...)     Serial.println(__VA_ARGS__);
#else
#define D_SerialBegin(bauds);
#define D_print(...);
#define D_write(...);
#define D_println(...);
#endif

then change all your
 

Change
Serial.print();
to
D_print();

and

Serial.println();
to
D_println();

Works like a charm to switch the serial print on or off
You can even add a button to do it for you if you are lazy like me 🤣

Edited January 7, 20242 yr by WannabeSolarSparky

Good tip, thanks...

I'd tried using this method before :

#define DEBUG 0

#if DEBUG == 1
#define debug(x) Serial.print(x)
#define debugln(x) Serial.println(x)
#else
#define debug(x)
#define debugln(x)
#endif

.. but it all goes to hell when you're dealing with floats (i.e. more than one argument - the second defining the decimal places to be printed).  But your method seems to cope with that, no problem.  I'll be using that in the future. 👍

I do try to only enable one 'print' at a time, though - especially when dealing with 'timing critical' stuff, like these microsecond LED dimming loops.

There's still always the trusty 'Search: Serial.print >replace with> //Serial.print', too. 😆

Just received the dashboard frame and 1st test print 🙃🎉