== last update 10/06/2021 ==

The Ferry clock. - Final Project making

In the beginning of Fabacademy I wrote the project plan. Since then many weeks have passed and I have found myself not able to work much on my final project. The reason is that I was not able to set on many aspects of the final project and it did not consolidate in my mind what it should do, how it should look and what technology was best used to achieve this.

But now this has changed and I think I can move forward. I will start by listing the obligatory questions from Neil and answer them to my best abilities.

Requirements

In order to make a usefull project I hereby list the requirements of the final project.

It should be interaction free: the user can retrieve the information they need without pushing buttons or any other interaction. (like a clock, doh)
Information should be understandable for adults and children
Information should be reliable.
The clock should be updatable.
the clock should have a nice fancy appearance. Either a nixie-clock like appearance or an 80's equalizer style appearance.
If the clock depends on light, this light should be bright as the clock should be legible in daylight.
the clock should inform its users on the ultimate 'just-in-time-departure' time.
the clock primary function is to inform on the departure times of ferries.
But other 'departure' times can also be programmed in: shool, work, sport, appointment 'departures', are all possibilities.

Research, tips and other important links

Bright LED at Digikey
Radar setup tutorial
https://forum.arduino.cc/t/lighting-leds-by-time-schedule/118481
https://forum.arduino.cc/t/turn-on-and-off-a-light-at-a-specific-hour/537301/8
https://randomnerdtutorials.com/esp32-ntp-client-date-time-arduino-ide/
https://diyprojects.io/esp32-timers-alarms-interrupts-arduino-code/
https://diyprojects.io/esp8266-deep-sleep-mode-test-wake-pir-motion-detector/
https://forum.arduino.cc/t/lighting-leds-by-time-schedule/118481

Design questions and thoughts

Main question to be asked and answered: should the clock be function centric or user centric?

With this I mean that the clock can show the time a ferry will leave and use its time table for that. Or the clock can show the time a user should leave the house, based on pre-programmed predictions or even based on electronic agenda synchronization... 🤔

After a long shower and an hour of running I decide, also for reasons of complexity, that for now I will go for the 80's synthesizer style-clock, indicating the time to leave. This is based on a combination of the actual time of arrival and the travel time to get there. So, for instance: the ferry leaves at 09:01, travel time is 6 minutes: at 08:55 I have to leave. Before that time the light is green, after that time the light is red. During that time the light is orange.

Here is a quick mockup.

While considering this, I think I can scale it down even more. I'll keep the design, but make it smaller: 3 indicators is enough as one ferry goes all the time, the fifth ferry is too far away anyway. Only two ferries really matter... and when school starts. So three indicators, which should be pretty predictable and not require updating more then like once a year or so.

I decide to use an ESP32 and a doppler radar for switching the thing on to make sure the LED's are only on when there is someone their to look at it. After all, we do not even know for sure if a clock shows time when there is no one looking at it...

After a talk on FA-global time I had some more ideas. Mostly to make it simpler.

Make a double side board... One side has the LED's; the other side the ATtiny and resistors...
use small LED's on board: Yes! Probably even the bright ones Neil

An ESP32 board with radar and LEDs

The heart of my clock will be an ESP32. I could use a less powerfull ATtiny, but want to keep the options for future development as open as possible.

The design requirements are:

A double sided PCB
9 LED's on one side
an ESP32 on the other side.
a doppler radar on the same side as the ESP32
An USB power connecter -> this was later dropped due to Henks advice. He said that USB connectors break easily. I will go for powercables attached to an external adapter.

And I think that these design requirements translate really well to spirals. :-)

Double Sided PCB

The double sided PCB has been the toughest part of the assignment (so far). In the end I succeeded, but that did not go without a hitch. Here I will detail for Roland MX20 users how I did it and what you have to look out for.

Tips and resources and thnx for achieving success go to:

Adrian Torres. Quentin Bolsee This digikey tutorial into Kicad.

The F-Key.

First of all, if you want to have components on two sides of the board, you need to place them on another layer in KiCad. This is done by pressing the F-button. F stands for flip.

You can also choose in the upper menu of Kicad PCB layout editor on which layer you want to draw and even assign keyboard shortcuts to flip while routing! In the end it feels like a crazy luxury to have an extra layer. No nice route to be found? No problem, just drill a via! (Vias can be found in the menu on the right.)

What also helps, is a nice thick copper pour so that the board looks nice ánd traces to ground are not needed.

Designing an ESP32 based board.

Following the basic setup of Neils ESP32-WROOM board I start out by aligning the components much the same as he did.

I make the following alterations:

The board will be double sided and I break out 10 pins that go through a via to the other side where the LED's will be placed.
There will also be a GND connection needed to the other side.
I add a doppler radar so that movement will wake up the ESP32 from deep sleep.

So far this all has created the following issues:

how do I define the right space for the vias?
there is no item in the fab library for pins pointing upwards: so there is no associated footprint. I probably have to make this myself...
the radar is rather big. I am not sure if I want to keep it on the board, or connect it with wires and be more flexible in its placement.
Also I'll need to test the proper position of the radar so that the hallway is measured and not people walking in front of my house.
There also needs a ground next to Tx/Rx as common ground.

In my previous life I often designed printable materials. Always when you thought your thing was done for printing, I was halfway. The same law applies to board and milling it seems...

I showed my work to Henk and asked him for comments. Surely enough he had some remarks:

Registration marks are not gonna happen: I am not allowed to drill into the sacrificial layer.
USB ports are shit: they often come off
I am one pin short of a full fledged FTDI connection. So why not add that one pin?

After some more pressing Henk was also able to explain me the way forward, instead of only saying what was wrong. His tips were:

Make tabs on all four sides of the board of 0.8mm wide: the size of the cut-out drill. Make these tabs asymmetrical. They will keep the board in place when you flip it around. (see art-drawing below for a visual explanation.)
Just fix two wires to your board: red for plus and black for minus.
Replace the three pins I have now with an FTDI pin. This is basically the same as I have now, but adds a VCC pin.

Especially the last tip will create some extra work; there is no power near the place where the pins are now, so I'll have to move them... somewhere...

Adding logo fun

To give my board a little more personality I made a little logo for it. There was a nice tutorial online on how to add vector art to kicad that included numerous, rather complicated steps. (like modifying exported graphic files in a text editor to change the layer on which the graphic should end.)

Everytime I am done in Kicad, I export to SVG, open that file in Illustrator and convert to PNG. In that step I can also just add the logo in the svg file in Illustrator and get direct WYSIWYG goodness.

A good thing to remember here is that, with negative-art, you need to make sure that the traces are 0.4mm or wider. Otherwise your little fun drawings will dissapear in mods.

Making the traces thicker

The Radar

This humble piece of hardware was almost forgotten by me... I did reserve a big swath of room on the board for it; but almost only connected the GND and 3V3... Going back to one of the finest tutorials by Floris Wouterlood I read that the radar can be attached to virtually any Arduino pin. As the ESP32 is also very forgiving in which pin you use for what I'll just be oppertunistic and take one of the general pins that is most easily reachable.

Also I am adviced by numerous comments online to prodive the radar with 5V as this will make it more reliable. I connect it directly to the 5V source.

To test the radar I used the code from input devices week 12 You can fine the code here

Connection and functioning.

I connected the radar in the end to the front of the board, which will be, when it hangs on the wall, the back of the board. It is connected with a three header pin. This helped me to make the back really flush and the LED's press against the acrylic front.

The main problem is now is that there is a big piece of copper in front of the radar. This prevents proper functioning. If I have time left I will unsolder it and attach wires to it so I can place it somewhere else. But the be honest; I should just have placed it on the front.

Registration and invertness - Board #1

When you are going to have a double sided PCB, you want to make sure that the board is in the same place when you flip it over. In global open time I was advice to drill holes into the sacrificial layer and put a drillbit in there as a registration marker. This is not allowed at Waag. So we do it differently.

On al four sided you have to place tabs of the same size as the drill bit diameter. This way you can flip the board after you perform cutout and it will stay in the right position. (or so we think at this moment, stay tuned for what happens later!). Make sure you make the tabs asymmetrical, so that the tabs do not fit in each other, but push against the walls of the cutout.

In my case the tabs need to be 0.8mm. And I draw them in KiCad.

I export the front, back and cutout layers to SVGs. There are a few features I need to pay close attention to:

Kicad drew the pockets under the program switch as holes. But these are not holes, these are pockets.
the vias need to be drilled with the same bit as the cutout. But not in the same go.

So basically I need to create five files for each of these operations. Also I need to measure the thickness of the copperplate as this might differ from the single layer PCB's we have used to far.

these are the five files as PNG that I will use to mill my board.

I first had to replace the single copper layer that was already there with my fresh double sided copper one. The thickness of the double sided copper layer is 1.64mm That is only 0.04mm thicker then the single layer copper one.

I set the right speeds and feeds, insert the right mill, restart mods twice for a stable connection, set the xyz origins and then send the file to the milling machine. Where it start milling away perfectly all the parts that should have stayed.

I forgot to INVERT the image 🤦‍♂️ (I blame Marleen for distracting me with talks about techpolitics)

As I only found this out after my lunch, basically most of the board has already been milled, so the whole surface is useless. Apart... I can still use this board to practice the other features.

I stop the milling and replace the 0.4 bit for a 0.8 bit. I then drill the vias and perform the cutout action. Then I flip the board and find out that the tabs are not really usefull: the board still has freedom to rotate. So I need to rethink where I put the tabs and how I make them.

Another issue I found out this way is that you do have to drill a little further then the thickness of the board in order to make the hole. The copper bends a little and is pushed out, instead of being milled.

Solder pads issues - Board #2

I make adjustments to the board and export the files and mill.

When ready both me and Erwin are stumped that the mill did not even attempt to mill between the solder pads of the ESP32.

After measuring in Illustrator and in Kicad, I can only conclude that the space between the pads is 0.37mm Which is too little for our 0.4 milling bit and hence can't be milled.

Henk claims that it is 0.56mm by sharing a screenshot in the mattermos chat.

Luckily Quentin Bolsee is able to help untie the knot and concludes that we are both are right. He finds out that probably I have no link between the fab_ESP32_VROOM symbol and the fab_ESP32_VROOM footprint. As Kicad has a default footprint for the ESP32, it picks that one. The fab_ESP32_VROOM footprint has modified solder pads to allow for 0.4 milling bits to pass through. Quentin also shared the right footprint with me. I have already manually modified my files. But maybe it helps someone else.

In order to improve this in the future, this tutorial on the KiCad forum could also be usefull.

Pixel/SVG drama - Board #3, #4

In my next four boards I was unable to get the holes in the right place. This was due to two, unrelated, issues. In board 3 and 4 I discovered the first issue:

Pixel perfectness in Adobe Illustrator screws up your SVGs

When you export your file from Kicad to SVG, make a modification, close the file and reopen it you will find that some parts of the drawing have moved a few pixels.

These black dots should be nicely aligned with their surrounding and not co-centric...

This is related to Ai trying to be smart and make your drawing pixel perfect.

This video is a demo of what happens. You see me open the SVG, make a modification, save the file, and reopen it. I then point out where stuff has moved

The best way to prevent this is to open the SVG and immediately save it as .ai file. In the .ai file you can work without fear of unexpected alterations.

I think this must have happened before with other boards as well, but only became apparent when I tried to mill double sided board as here every pixel counts.

0.8mm riddles - Board #5

0.8 mm drill causes 0.8mm difference on the back.

When you use tabs as registration method there will be 0.8mm drilled away around the board. When you then flip the board, this 0.8mm is used by the tab, moving everything slightly.

Due to the many failing boards I did painstaking research to find out how much moving was going on by slightly changing the origin. I first measured how much I was off by somewhat using a caliper. (this is really hard at such small sizes)

I then changed the origin somewhat and drilled in thin air just above my board to check if this was right. I did this several time, and came to 0.85mm

Only a day after doing this research manually and being successfull at changing the origin based on my visual estimates, the coin drops. The offset of 0.85mm is of course very close to the mill bit diameter. And I could have figured this little movement out way earlier and before. But hey, that is what experiments are for: to reveal to the observer what has been there for ages. Imagine a paleontologist saying on discovering a new dinosaur: "meh it has been here for over 2 million years and only now I found out about it... I am so stupid!". Right? Right!

So what could possibly go wrong now that we have everything in place? Well...

The 0,8mm millbit was not tight enough to stay in place. During the last, final run it came loose and made a deep and ugly cut across the board... 🤦‍♂️

Up and onwards to:

Mill massacre - Board #6

With board six I had everything under control. My vector files where debugged and my PNGs exported just fine. The front was milled, the switch holes made, the vias perfect in place, the board cutout done and looked nice, the origin moved 0.8mm to the right and I reinserted the 0,4 millbit for the back traces. And when off to grab a bite.

Upon my return to the machineI found that masacre had ensued.

The 0.4mm millbit had also come loose, kicked the board out of place and drilled ugly big wound in both my board and the sacrificial layer. The machine was still aimlessly milling in thin air.

Hall of Fail.

By now I had six failed board and was at the end of my rope. This past 5 months I had grown fond of the small milling machine and was able to operate it to mill board left and right quickly. But now, when it mattered most, I failed and flunked and destroyed boards like Zeus destroyed titans.

So to commamorate all the fallen boards. And to set my mind on something else, something positive, I made a Hall of Fail of lasercut acrylic.

Notice that I left one spot open on purpose, because... well I still had to mill a board. And that board, was board number 7.

Board #7

And that went fine. All the mistakes had been made by now it seems. So I finally dared to demonstrate my doings in the bright daylight.

Vias to rivets

Normally, after milling comes soldering, but not when you have double sided board... then you first have to add rivets. (pronounce as ribbit)

The vias turned out to be too small. Next time, when you want to make sure your vias are good; use the 1mm drill bit.

After that I could put in the rivets. Here it is important to note that both the top part of the via tool has to have a protruding tip. Our bottom part was flat with a tiny hole in the middle where the pin should have been. And of course all vias made there where crooked and ugly and bended on one side.

A pin on both side ensure that the hole of the via stays a hole and that the copper bends outside. Luckily we also had a 0.8mm via drilltool that had pins on both sides and that I could use.

and that is how, finally the connection is made between the two distinct sides of the board. Now, do note that there are holes meant for pin-thorugh-hole pins. The one for the FTDI and the one for the radar for example. You could put vias in those holes, but You'll probably make them too small for the pins to pass through. No worries, you can force them in, like I did, and you'll be fine. But you can also save yourself this excitement and problems: leave the vias out of the holes for pins...

Soldering

You can read more about the why's of my LED's in the chapter below. For the soldering part it is important to know that the LED's are reaeaealy small and the solder pads are on the bottom of the LEDs. So you have to use a reflow method to make 'em stick.

At Waag we have a little syringe with a sticky solderpaste in it. You use that to put tiny drops of paste on the right places in the board. I found it really hard to limit the amount as the paste also sticks to the mouth of the syringe and in order to let it drop you have to push more solderpaste out. Which, by then is then too much. So I resorted to putting too much paste on one place and then deviding the pasta with a tweezer over two solderpads.

I then pressed the LED's in the solder paste and heated the solder with a heat gun.

The benefits of using solder paste are somewhat overrated imho. But when I tested all my solder connections with a multimeter, and one was not good, I used normal solder to make a new bed for the LED. When I tried to melt the solder under the LED with a heatgun, the LED blew off. The stickyness of solderpaste does help in this regard. I think I can do fine with normal solder. I just have to make sure I keep the component in place with a tweezer.

The other side of the board, with the ESP and some resistors, capacitors, regulators and buttons was just straight forward soldering.

Charlieplexing or normal led connections?

Charlieplexing allows you to drive up to N*(N-1) LEDs using only N pins on microcontroller. Keep in mind that you can always use fewer. source: Charlieplexing Made Easy (and What It Even Means?!)

Building on Nadiehs' charlieplexing adventures I will try to make my own board in KiCad. After digging through some manuals, explanations and examples I am still not 100% able to explain charlieplexing in my own words to someone else. But I do think I have enough knowledge under my belt to be able to draw the schematic I need in KiCad.

Still... after reading a little more on the way Charlieplexing actually works... I am not entirely sure why I should even do this. There are, after all, enough pins on the ESP32 to drive 9 LED's. And even 10 LED's. As I think I will add another LED just to signal that the system is on and working.

Benefits of Charlieplexing:

Less pins on MCU needed
less resistors on board needed
learning something new

Benefits of 'normal' connections

Less complexity in code and thinking
brighter LED's as each has their own resistor and you don't have to modulate them if you want two on at the same time.

The board I made in the input devices week is very well equipped to test all my needs... I can even at the Radar to it.

That I did not make that board in KiCad, will now haunt me. As I want to use the part for programming and basic power control from the schematics of Neil. Luckily there will always be other students who have done this.

New insights on LED's

I had three epiphanies this weekend:

the LED's I am using are signal LED's. They won't be very usefull to transmit light to see from a distance in a bright hallway. I need these LED's as shown by Neil in his output devices lecture and as shown on the output devices week page. But then I stumble down a rabbit hole of mosfets and other unthreaded teritory... Another option would be to use the brighter RGB LED's. But these require way more transistors... space I do not have and do not want to create.
The red leds at the bottom of my design will always be on. So I might as well wire them together to one pin. Basically all they need to do is listen to the radar. If a person passes by, they turn on, stay on for 10 seconds and then turn off.
As they will always be on when someone is looking at them, the need for a tenth LED is gone. I visioned the tenth LED to be some kind of status LED; to show you that the device is powered. But the RED leds are now performing this function.

Taking this into account I want to make some changes to my already designed and, so far unsuccessfully milled, board.

Replace the 499Ω resistors with something that fits my new need. A quick calculation on the digikey website gave me 3Ω as resistor.
Source voltage is 3.3
LED voltage is 2.85
Max LED current: 150mA
But this is based on the Max LED current, which makes the LED shine very very bright. And I want something dimmer...
A quick read up on serial vs parallel wiring of LED's tells me I can probably wire the red LED's to one pin in serial using one resistor.
The tenth LED can simply be eliminated.

This is the result so far.

I also removed the global labels to LED 6, 9 and 10 from the ESP32.

From serial to parallel.

The main thing that confuses me are the implications of serial vs parallel wiring of my LED's. And if the ESP32 is even capable to deliver all this power to all these LED's...

I think I will start by doing a little test with making two setups on breadboards: one parallel and one series:

On the left you can see three LED's in parallel and on the right two LEDs in series. The two LED's in series have much less brightness then the three in parallel. The Parallel LED's have so much more brightness that my camera even has issues seeing the other two.

So, what everyone probably had seen coming a long time ago, has finally occurred to me. I made a fundamental mistake in my design. Putting my LED's in serial was not a good idea.

When you put LED's in series, each LED's will share the power. So if there is the same power, but more LED's the shine less bright.

So, I first am going to redesign the board...

Reworking the KiCad design

After taking these new considerations into account I did a big rework of my KiCad design. There were some smaller things already bugging me and this allowed me to redo a lot and make it better. The most changes are related to the removing of the tenth led and putting three LED's in serial. This saved a lot of room. The most important are:

vias are no longer under the ESP32, but next to it.
radar is now connected to 5V, instead of 3.3 (I got adviced as this improves the reliability)
the board is smaller.
I removed all unused ESp32 solderpads: this make the board cleaner and will save on milling time. (Henk later adviced me not to do this: so much connected copper under unused pads can also cause short-cuts)
removed the copper under the radar: I hope this has some kind of positive effect on reliance of the radar. (I somehow forgot about this later on... luckily it does not affect the final product)

Also, I checked carefully the vias diameter. This is really 0.8mm. Every time I drilled so far, the holes seem smaller. Which is odd as I also used the 0.8 drilling bit. This is something to closely watch when drilling again.

NOTE Only now I realise that the new LED's are of course not the same size! According to the datasheets

the old LED's are: 1.60x3.20mm
the new LED's are: 1.40x3.00mm

So the new LED's are smaller... that is less of an issue then the other way around. Pfew. But I might have to do some redesigning... again...

Following the manual bij Digikey on youtube I create my own footprint. Or, as Loes tells me, I can also download it from Snapeda

Much easier...

Note the I took carefull consideration to let the copper extrude from the side of the LED so that it will be easier to solder; solder can now flow to an easily accessible and viewable place.

I feel some resistance...

Then I got advice from the community in general and Rico Kanthatham) specifically:

to check out brightness...easiest just to use a power supply...set to 2.85V...and use jumper wire tips to power the LED to see how bright it is ...lower the voltage or add a resistor to control the brightness...or just a small potentiometer to be able to adjust the brightness by turning a dial ...a roundabout way of saying...no need to make a pcb...just test using a breadboard.

And that is exactly what we are going to try now.

In this setup I could easily and quickly change the pin-through-hole resistors and check which one would dim the LED to the just nice brightness. I liked the 100Ω resistor, but decided to go for 49Ω in the end as I was not yet sure which kind of light filter I was going to use.

pin 34 & 35

One thing I did not carefull consider, and that would only bite me all the way at the end, was that I did not carefully checked the functions of all ESP32 pins. Pin 34 and 35 turned out to be input only. So the two LED's attached to those pins are not doing anything... If all is finished I will try to do this with either an overbypass: making two wires cross the ESP32 overhead and connecting the LED's to two free GPIO pins.

Or I can desolder the ESp32 and try to put a vinyl mask with copper on top under the ESP32. This would also bring me the oppertunity to vinylcut copper. But, this is one of the nice to have extra spirals.

Boxee Design

All what I make has to fit in a nice box. These chapters details the research and different experiments I made with that.

In an earlier stage I experimented with multiple acrylic layers. I want to have at least one clear acrylic layer on the front of my box as this will give it a nice shining. And I can maybe etch a logo or name in there. I then went to wood and to 3D printed material only to come back to acrylic in the end...

Wood and acrylic

It took me some time to get the right power and speed as I haven't used the lasercutter so much in the past weeks.

But in the end I had multiple layers of wood that gave me a nice impression of what the box could look like. But I want something more colour full and play with a stacked layer of different acrylic pieces to see how that might look.

I like the bright colours. Light leaking on the edges is a feature in this design. But I think the box is too thick and I want to work towards a design with less layers.

3D print

I now want to check if I can make some parts of this boxee (I don't know why I call it that way, but I like it) on my own 3D printer. Specifically I want to print a piece that:

has a very thin white layer: this should be so thin that it hides the components, but lets the LEDs shine through
has a black layer on top of it, functioning as:
a mask; covering the non-LED parts
holds the filters (for color)
holds the board.
has mounting holes to attach it to the acrylic.
has holes to mount it to the wall
has holes for a power source.

I could not just import the SVG of my KiCad board design into Fusion360 in the sketch plane. I first had to open the file in Illustrator and save it again. Then placing the SVG in the sketch plane seemed to create the exact correct dimensions, so I can immediately start building the layers. But it turned out that the dimensions where not correct... This is a known scaling issue of SVG that can be resolved.

After importing you can scale the imported file. After consulting online and a lot of back and forth I conclude that the scaling factor should be 1.33 Then the Fusion file matches the Illustrator file.

Another important thing to remember is to clean up your SVG before you place it in Fusion. Illustrator adds a lot of anchors to an SVG that are really not needed and these slow down any form of sketching and drawing in Fusion360. So make sure to delete anchors.

PLA circuit board

I first make a littlefake PCB. I notice that I am having issues in my head to keep all 3D factors and shapes in place and design accordingly. It helps me to have the actual object in my hand. And since my PCB milling failed and I do not have the object in my hand, I print one.

With the kicad SVG opened in Illustrator I make a bunch of alteration so I can import it in Fusion360 and work from there.

The kicad file has many, connected traces. So I need to do a lot of cutting and anchor removing to make path editable. As there is repetition in the design (LED/R combinations are identical) I decide to clean up only one part and copy it to the rest.

This results in a cleaner overview of all the components on the front that are extruding from the copper. Here you can see the R and LED combinations and at the bottom the big rectangle is the radar module that will be soldered to the front.

I use this design to make a quick first print:

This is not what it should look like.

the board is too small.
the components are four dots, where they should be two rectangles.

It is funny how these things reveal themselves to me only after I hold the physical object in my hand...

I make some alterations to the design in Illustrator and make a new 3D design in Fusion360.

Using the datasheets of the new LED and caliper measurements of the radar at home I make and print the board again.

This looks a lot more like the actual thing I expect to hold in my hand when coppermilling and soldering of the actual board will be done. One thing to note though is that the dimensions are off. There is an error margin in my printer that I need to investigate some day.

For example, I set the bottom plate to be 1mm, but it is 0.7 after printing.

The Boxee

After that I make a black box that has pockets for the radar and tunnels for the LEDs to shine through. The purpose of the black box is to package the PCB and to prevent the LED's from leaking light. I want to keep their light beams seperated.

You can see that I made depressions in the design for the radar, and for each R/LED-pair. I was first thinking to separate the LED and the R. But This becomes a lot of tiny fuzzing and I am already pushing the resolution of my 3D printer.

White cover and colour filter holder.

To top the design off I make a white PLA layer to put on top of the box. This give a nice flat finish to the whole box that can be covered by a transparent acrylic layer. The cover will consist of a 3mm thick layer that has 3 spare outs for the color filter to be inserted in. The parts where the colour filters are put in have a top layer of only 0.12mm. This is the thinnest layer my Ender3 should be able to make. I hope it will cover the filter, create a continues plane on the top, but still be thin enough for light to pass through.

The whole thing

Here are the three parts I printed to test how it might look.

I had some colour filter laying around that I used for testing.

But everything combined I can't say that I am impressed. Mostly I discover that my 3D printing skills are good enough for functional stuff, but not to make something of beauty. And I decide to lay this aside for now. The box won't make it into the final design, but it did help me make some other choices:

colour filters in front of the lamps are nice.
I like a thin design.

Back to acrylic.

Using the now very well understood kicad design files, I quickly make an SVG for the lasercutter and use it to cut some parts out of some nice acrylic. I'll use:

One clear front for the LED's to shine through
Two different colours that can hold the PCB (mind the cutout of the ESP32 antenna which is of course not present in my KiCad cutout file)
A back that has room for the FTDI pins to stick out and allow me to flip the program/run switch.

Not the somewhat weird shaped hole in the backcover. I made this so that, when the clock is mounted on the wall, the powercable can extrude from the right side; the direction in which I have a power socket in my home.

For the rounds I use acrylic 'sticks' that we have at de Waag. As per advice of Michelle I cut out a rectangle of a derelict piece of acrylic. This I will use to make sure that the cuts in the sticks will be perfectly straight.

At first I made one clear and one black acrylic front. I like the black as the coloured parts stand out more. But the clear one reveals the nice PCB underneath it. I find it hard to choose either one...

After asking Paula for her opinion, she convinces me to go for a coloured front instead. I decided to go for a brownish coffee coloured part in the hope that it will add some '70's feel to the design.

And I must say, that, together with the orange and the red, it suddenly feels very much like 1978 again...

Sadly the acrylic I used to fill up the holes does not match the colour of the acrylic on the sides. I want to improve on this in a next iteration.

Also the radar board is slightly thicker then I expected, so the back panel can't be screwed to tight. Either I need to leave more room in the cutout on the back, or I need to add an extra layer. (but that would make the entire box thicker...)

In the final iteration I added on extra hole on the back so I can quickly press the reset button..

Wall mount.

To complete the design I 3D printed a wall mount. It has two holes for screwing it to the wall. The diameter of the holes match the random two screws I had laying around on my desk and the holes have a slightly sunken part so that the front will be completely flat.

Features:

two hooks to holed the boxee
extended pockets for the bolts of the boxee to slight into
square pocket for FTDI and radar pins to sink into.

I printed this part on my Ender3 at home using PLA filament. It was sliced at normal quality use Cura ULtimaker software.

The end result fits nicely and can be used perfectly to mount the clock on the wall.

Powerrrrr!

I need to calculate at one point what the powerconsumption is of my entire project. This is not something I just thought of. I was told to do this by Rico Kanthatham. He also shared this tutorial with me to save energy consumption on the ESP32.

Proper power consumption calculation is something I will need to do with another project. With this project I must admit that I followed the ballpark/yolo approach. That the ESP32 needed 3.3V and the radar 5V was clear from the onset. How much the LED's needed not so much. But I was able to solder one to a wire and hook that up to a powerbank. With 3.3V it lit up nicely.

The big question remains if they will also all lit up nicely when I attach 9 bright LED's to the ESP32 and if that can all be powered from a 5V USB adapter...

With this basic setup I want to power the module.

I have cut the USB cable at the mini-usb end and soldered the cable to two wires I already had attached to the board.

Not that I made two holes in my board for power and two holes for GND. Following the example of the Fabschoolino I thought that weaving the cables through two holes will help absorb any external stress on the cable. Sadly I found that weaving is really hard with such a tiny little piece of copper. Also the holes where too close together.

I am not super happy with this result: a clunky wire not attached to my two holes. Which is soldered to a USB cable, which is black. While the wall on which this thing will hang is white.

So I decide to redo this part and end up with a stronly soldered, and woven through two holes, white USB cable:

As a token of appreciation for this perfection the power gods also decide that the powersource is more then enough to power ESP32, LED's ánd radar.

Code and data.

The data of the IJveer is not available in the standard open database. The plan now is to use the official timetable and hardcode the ferry times into the ESP32.

States of the clock

All LED's are off when the radar has not detected motion for more then 10 seconds.

For any given column of LEDs the following is true:

If only the Red LED is on, you are too late.
If the red and the orange LED are on, you have to hurry
If the red, the orange and the green LED are on, you are on time (or too early)

A quick break down reveals that '6' numbers are needed.

Summing it up:

There are 9 LEDs.
The Red LED's will always be on.
If the Green LED is on, the Orange LED is also on.
There are 6 possible states.

**NOTE: as the pins 34 an 35 are not connected I have two green LEDs not working. I make this bug into a feature and will only display IJplein ferry departure for now. But I will do this much more finegrained:

All LED's on: all the time:
Green LED goes off: time to get ready
Another orange LED off: time to go
Another Orange LED off: Hurry!
All orange and green LED's off and only RED LEDs on: too late...

A clock script - pseudo code.

LED's are off
a motion detected by the radar wakes the ESP32 up
The ESP32 queries the server
The ESP32 receives a number from 1 to 6
Depending on the number the ESP32 switches on the corresponding LED's
Repeat from step 2
If no motion is detected for more then 20 seconds, ESP32 goes into deepsleep.

Testing the board primary functions with existing code:

To test the working of the ESP32 I used the SimpleTime sketch example. The code I used for the ESP32 time sketch: SimpleTime

I testes the LED's using a mismasj of blinktest and code I made myself. The code I used for the LED test: LED test

To test the radar I used the code from input devices week 12 and added the LED's from my clock. You can fine the code here

Testing time.

The hardest part, I think, is getting the right time into the board and tying a certain event to a certain time.

Between 06:00 and 18:00
start at 06:00 and repeat every 6 minutes:
If time left to departure is > 8 minutes; all leds are on
If time left to departure is 8 minutes; three orange led's and red led is on
If time left to departure is 7 minutes; two orange leds are and red led is on.
If time left to departure is 6 minutes; orange led is and red led is on.
If time left to departure is 5 or 4 minutes: red led is on
If time left to departure is <4 minutes; all leds are on again as there is now more then enough time to catch the next one.
Between 18:00 and 00:00
start at 18:00 and repeat every 12 minutes:
If time left to departure is > 8 minutes; all leds are on
If time left to departure is 8 minutes; three orange led's and red led is on
If time left to departure is 7 minutes; two orange leds are and red led is on.
If time left to departure is 6 minutes; orange led is and red led is on.
If time left to departure is 5, 4, 3, 2, 1 or 0 minutes: red led is on

testing coding time

I started my search for the lost time with a RandomNerdTutorial. I then got a code snippet from Erwin: if (timeHour == 9) { // do stuff }.

That gave me an error:

error: ISO C++ forbids comparison between pointer and integer [-fpermissive] if (timeHour == 20)

Luckily someone else followed the same tutorial and had the same error. This Reddit discussion had the solution.

That resulted in Time Test #1

It feels like I have now taken the biggest hurdle... The Red LED's on my clock light up after 8pm. And that feels like quite the achievement..

From there on I investigated a little with making smart formulas to indicate time, but all failed. I am not so smart... So I ended up in hardcoding almost all times in long lists in the code itself. This works!

You can find the final code in the source files list below.

Source files

#	Description	Files
1	3D Printed wall mount	STL
2	Casing	ai and svg
3	Code for ArduinoIDE	.ino
4	Kicad Files	all in one .zip
5	Milling files (in order of milling)	traces front, pockets, vias, cutout, traces back

End result.

The end?

Clearly this is not the end. Even though the clock performs its function, it is not yet as cool as I would like it to be. Nou doubt I'll be milling again somewhere the coming weeks and make a new version.

In that second version I want to solve the following things:

Check pins before milling and connect two green LED's to other pins.
don't put copper in front of antennas
don't put copper under unused pads. This just feels better...
keep all LED's separate (not in parallel) for more flexibility.
FTDI is overrated: 4 pins are more then enough for anyone.
Use color coordinated acrylic plates for casing and LED filters.

If there would ever come a third version this are some of the things on my wishlist:

allow over the air reprogramming
sync (part of the) clock with Caldav agenda.
make a mobile version that uses gps and battery so you can also use it when you are moving.

But for now my focus will shift to other things first. If you came this far reading my documentation, I would like to thank you very much for your attention! I hope you enjoyed it and that maybe I even get to hear from you.

Bye!