I've always enjoyed coding challenges; obviously at work but also every so often just for fun, usually from a coding-exercise site such as CodingBat or CodinGame. So I thought that I'd try my hand at imagining, writing and finally solving a coding challenge myself:

The challenge

You're tasked with implementing a module of an ordering system for a self-service restaurant. When a customer places an order, they shall receive a pickup number which is called when their order is ready for pickup at the counter. To avoid confusion, the order numbers shall have a configurable cooldown period after the food was picked up in which they may not be assigned again. The numbers of the orders which are currently prepared and the ones of the orders that are ready for pickup shall also be displayed to both the customers and the staff. The first number shall be configurable (at any time).

In coding terms, implement this interface:

public interface IOrderPickupNumberSystem
{
    /// <summary>
    /// Configures the (inclusive) lower minimum order number.
    /// </summary>
    int MinOrderNumber { get; set; }

    TimeSpan OrderNumberCooldown { get; set; }

    /// <summary>
    /// Gets the next free order number and marks it as "in preparation"
    /// </summary>
    int GetNextIdleOrderNumber();

    /// <returns>
    /// All order number which are currently being prepared.
    /// </returns>
    int[] GetOrderNumbersInPreparation();

    /// <returns>
    /// All order number which are waiting for customer pickup.
    /// </returns>    
    int[] GetOrderNumbersReadyForPickup();

    /// <summary>
    /// Marks the order with the specified number as "ready for pickup".
    /// </summary>
    void SetOrderReady(int orderNumber);

    /// <summary>
    /// Gets the total number of order numbers, regardless of status.
    /// </summary>
    int GetOrderNumberPoolSize();

    /// <summary>
    /// Marks the order with the specified number as picked up and initiates the
    /// cooldown.
    /// </summary>
    void SetOrderPickedUp(int orderNumber);
}

Implement yourself

If you want to take the challenge and implement this yourself, clone the repo at the end of this post, delete the contents of the OrderPickupNumberSystem class and have Visual Studio add the method stubs of the interface. When you're finished run the unit tests in the separate testing project to verify your work.

Solution

The data structure

Firstly, this system of unique numbers that have data attached to them screams database. This is a classic primary key scenario and in any productive environment, it would be implemented as such. But for the purposes of this challenge, I decided to use next best thing: a dictionary. I always think of a dictionary as a mini in-memory database. Often, key and value are value data types, such as int and string, but they can really be anything. In this case, the key will represent the order number as an int and the value will be the status of the order number.

At first, one may think that an enum for the states of the order numbers is enough, but there is also the requirement for a configurable cooldown which an enum can definitely not satisfy. Usually, I like to use a strictly implicit approach with something like this, but this time I decided to include the Cooldown state in the enum and an extra DateTime? property for tracking the cooldown time. In the strictly implicit solution, there would be no extra state in the enum and the number would be considered in cooldown if the DateTime? property is set to a non-null value, taking precedence over the actual state denoted by the enum. But this also complicates working with the class.

Getting the next order number

I will describe the implementation of int GetNextIdleOrderNumber() in an iterative fashion:

1. At the core, the next order number is the minimum order number or the maximum existing order number + 1.
2. Before that, all existing order numbers must be checked for the first number in the Idle state that is greater than or equal to the minimum order number.
3. And at first, all existing order numbers must be refreshed in terms of the cooldown.

The info functions

For the int GetOrderNumberPoolSize(), int[] GetOrderNumbersInPreparation() and int[] GetOrderNumbersReadyForPickup() functions, we can simply use the Count property of the Dictionary and the Linq extensions respectively.

The setter functions

The setter functions, void SetOrderReady(int orderNumber) and void SetOrderPickedUp(int orderNumber), get the existing info of the specified order number, checks if a transition is possible to the desired state, sets the new state and, if the order has been picked up, sets the CooldownStart property to DateTime.Now.

GitHub - cronoxyd/OrderPickupNumberSystem

Contribute to cronoxyd/OrderPickupNumberSystem development by creating an account on GitHub.

GitHubcronoxyd

While on vacation in Sainte-Maxime, I had the luck to experience a single thunderstorm cell off in the distance and over the ocean. A first to me, I had to capture the beautiful display of ESD.

Starting from my research discussed in 3D printed diffusors, I designed somewhat of a hybrid that aims to consolidate all positive traits of the previous diffusers and incorporate the maxims I postulated at the end of the post.

The main points of this design are:

1. Compactness - the sources of light are arranged at an angle at the top and bottom behind the screen so that the circle of light is maximized.
2. Alignment - the intermediate diffuser is curved so that the light on it is approximately in the correct position for the screen.
3. Refraction - the light changes media 4 times before exiting the diffuser.
4. Distance - the sources of light are as far as possible from the screen.

The resulting illumination on the screen is very good compared to the trials:

But looking at the solarized version of the screen image, two problems can be identified.

1. The layer times are very visible on the screen and the intermediate diffuser, causing stripes to appear.
2. There is falloff on the side.

I plan to address these issues in the following ways:

1. Since striping was never a problem with the diffusers in the first post where the screen was thicker than one layer, the screen and intermediate diffuser will be thickened to at least two layers.
   
2. The sources of light will be rearranged to decrease distance from the sides.
   

I wanted to upgrade my voltmeter clock with illuminated voltmeters that react to the ambient level of brightness. So I had to design a new case for the voltmeter mechanics and electrics that included light guides or rather diffusers. This posed and interesting challenge and learning curve that I detail in the following. Now, I have yet to finish my research with this and I will post again when I evaluated new designs.

Hypothesis of operation

My first thought was to put as much plastic between the source of light and the screen as feasible. On the other hand, too much attenuation can lead to heavier falloff. I figured that the inverse square law where the intensity is inversely proportional to the square of the distance from the source (meaning that a point twice as far away receives only one quarter the light) would apply in plastic just as much as it does in air.

So with that, I decided to try both approaches.

Designs

In the following, I present my designs. The images of the outcome were taken indoors, both with the room light on and off. The settings for the camera were as follows:

V6

Reminiscent of a V-engine, this design aims to diffuse through both pointing the light source not directly at the screen as well as using generous amounts of plastic.

Rating: Very bad, because of the strong attenuation the falloff is severe.

Single-edge sidelight

Inspired by the Sony Watchmans CRT design, this design aims to both reflect and diffuse the source of light coming from the side.

Rating: Too much of a radial gradient, with light pooling at the edge. But the reach of the light is good, making it the opposite edge.

Sidelight

A simple arrangement, with the source of light directly firing at the edge of the screen.

Rating: Falloff too heavy, light sources are very visible.

Double sidelight

With an inner and outer diffuser, this design is meant to achieve diffusion through refraction.

Rating: Nice spread and milder falloff, but too much of a radial gradient.

Offset sidelight

Maximizing the size of the inner diffuser, this design is an "amplified" version of the double sidelight version.

Rating: Best diffuser so far with a minimal radial gradient and even light distribution. But where the intensity drops off abruptly in the middle where the arch touches the faceplate.

Conclusion

1. Using solid plastic as the diffuser is not feasible and induces the inverse square law too much.
2. Diffusion through refraction works well and reduces the usage of plastic.
3. Any solids through which light travels should not be thick enough that infill is necessary because the patterns are very visible (this is past knowledge and I have avoided this in the designs presented above).

Modern software now starts including features to sync settings (such as tool preferences) to a server, often the one from the software's vendor. This is pretty neat as it allows for better continuity when working across devices. But the majority of software still doesn't include this functionality. This is probably due to the fact that this is a continuous service that requires upkeep, maintenance and investment.
In this article, I will detail a method of implementing this synchronization of settings that worked quite well for me. To use this method for yourself you will need some cloud storage with local synchronization capabilities such as Microsoft OneDrive, Google Drive or Nextcloud. It is also advisable that the synchronization agent is running at system startup. You also need an operating system that supports symbolic links. In the case of Windows, you need an installation that runs on build 14972 or newer.
The following is a step-by-step manual on how to implement this method, explained by doing so for the software EPOS Gaming Suite, which is the configuration interface for my headset on Windows.

Step 1: Finding the setting files of the target software

There are 3 locations in which most software saves its settings and configuration files (on Windows):

• AppData (which can be navigated to by hitting Win+R, entering %APPDATA% and then hitting Enter)
• ProgramData (which can be found under the path C:\ProgramData)
• Documents (which would contain a folder named after the application or the application's vendor)

Some applications (especially old ones) save their settings in the Registry, in which case the implementation of this method would require a serialization of those registry entries, a hook to trigger it and then the reverse for remote changes.

For the EPOS Gaming Suite, the setting files are located in C:\ProgramData\EPOS\Gaming Suite. I chose to only sync the files in the subfolder CUSTOMPRESET because there were other directories with files that indicated being driver-specific. This choice also demonstrates the common sense and technical inclination you need to apply to successfully implement this method. Try to identify and exclude files that are machine-specific (such as driver configuration files) otherwise you may render the software unusable. Also try to identify the need to include a whole directory or just a couple of files. Here are a few things to look out for:

• A directory of files that indicate that more files may be created during runtime (such as file0.xml, file1.xml, file2.xml etc.).
• Files that may contain info specific to that machine (such as `recentprojects.xml` or `driverconfig.ini`).
• License files that could cause the software installation on a different machine to try and use the same license, causing a licensing conflict.

Step 2: Backup up the original files

Create a backup of the original files you located in step 1, just in case.

Step 3: Setting up your cloud file structure

This is of course up to you, but I chose to create a folder named AppData directly in the OneDrive folder. Then I activated the option Always keep on this device in the context menu for the entire folder. That is optional but good practice as it forces OneDrive to always keep the files up-to-date and to not delete the local copies during automatic cleanup.

Step 4: Copying the original setting files to the cloud and deleting the originals

Firstly, make sure that the software you're doing this for isn't running (don't forget to check for running services or tray icons as well).Then copy the setting files you located earlier into a subfolder of the AppData folder. I like to create a folder with the software's name and then either place the files into that folder or create another subfolder named after the original subfolder and place the files there.

So in case of the EPOS Gaming suite the original path of the files is C:\ProgramData\EPOS\Gaming Suite\CUSTOMPRESET and the path in my OneDrive is C:\Users\crono\OneDrive\AppData\EPOS Gaming Suite\CUSTOMPRESET.

Now you can delete the original folder (or file(s)) to prepare for the symbolic link. For the EPOS Gaming Suite I only deleted the CUSTOMPRESET folder and left the other files alone.

Step 5: Creating the symbolic link

Now it is time to make the software think that nothing changed. This is achieved using symbolic links.

Depending on your choices from step 1 (whether to target the entire directory, a sub-directory or individual files), you will need to create one or several symbolic links to recreate the exact file structure.

For the EPOS Gaming Suite I invoked the following PowerShell command in the C:\ProgramData\EPOS\Gaming Suite directory:

New-Item -ItemType SymbolicLink -Name "CUSTOMPRESET" -Value "C:\Users\crono\OneDrive\AppData\EPOS Gaming Suite\CUSTOMPRESET"

The New-Item cmdlet automatically detects whether the specified -Value is a directory or a file.
In case you want to stick to CLI tools, you can use the mklink utility but you need to specify that it is a directory using the /D switch:

mklink /D "CUSTOMPRESET" "C:\Users\crono\OneDrive\AppData\EPOS Gaming Suite\CUSTOMPRESET"

Step 6: Testing it out

After creating the symbolic links, double check the directory structure. Then, start the software and check if your settings are still as before. Next, make a change to your settings and save. If OneDrive starts syncing one of the files in the AppData directory, the upload works! To fully test the implementation, do the same process on another machine and check if the settings of the applications remain in sync.

Limitations and final words

It is important to remember that this method is (most likely) not something the developer of the software thought about in their implementation. It is a bodge and may break at any time. You may need to update the symbolic links or the directory structure in the future and you may experience crashes and data loss if something goes wrong. Here is a list of things to look out for:

• Updates of the software. This can not only pose a problem because the software may change the format of its setting files or the directory structure of its user-specific data but it may also delete and recreate the folder structure during an update (which will also wipe out your symbolic links).
• Concurrency conflicts. If you have implemented this on multiple machines on which you then run the software at the same time you may run into the problem that the one instance overwrites the data from the other. Remember that the content on screen is not necessarily the data on disk.
• Working offline or with a slow connection. Living in rural Germany, a slow internet connection is sadly still widespread (yes, even in 2021). Therefore, the sync agent may not have finished syncing recent changes when you launch the software. So you could run into a situation where you launch your software while the agent is still syncing the settings files and then the old version gets read by the software. Unaware of this situation you make changes to some unrelated settings and upon saving, the software overwrites the settings file with your local changes, wiping out the remote changes. Remember that Windows also automatically pauses syncing when the battery is low.
• Software running at system start. If, like my headset configuration interface, the software runs at system start, then the chance that the sync agent hasn't finished syncing the settings files dramatically increases. That wasn't really an issue with my headset software because I don't change the presets that often and if I notice a missing or old one, I'll simply restart the software.

As you can see, this method is quite involved when setting it up and cannot be guaranteed to run steadily. But I implemented this on my computers and I have been quite happy with the results. My headset presets as well as my development settings and swatches in the Affinity suite are available on all my computers, which has been very neat.

About 2 weeks ago, the PCBs arrived. They look really good and the silkscreen is nice and sharp. Total damage was 24,45€, not including any of the components. I have to say, this already feels a lot more formal than an empty perf board.

I ordered these PCBs with the full knowledge that I’d make some mistakes and sought to learn from them. So here are the flaws in my design which I aim to fix in the next version:

Power supply screw terminal

The screw terminal for the power connection had much wider pin spacing than anticipated. Luckily, the pads were large enough to drill an additional hole and then make the connection using a solder bridge.

Incoming ground connection

I failed to connect the ground of the incoming power supply to the rest of the circuit, rendering the whole PCB without power. A quite unnecessary mistake as it could have been avoided with a connection trace by hand of the final design. Still easy to fix with a little wire.

In this picture you can also see the hole I had to drill for the screw terminal (top left).

Reset button problems

This problem has nothing to do with the PCB but rather the socket for the ATmega that I soldered to it. During my initial testing, the reset button was only working sporadically and I spent quite some time before I figured out the problem: It was the spring contact in the socket. Notice the much larger gap of the last pin on the right compared to the one on the left in the photo. I reused this socket from another project and apparently damaged it when removing it from the old PCB.

It was difficult to track down since, whenever I touched the probe of my multimeter to the pin of the ATmega, I’d push it inwards slightly and it would make contact and work perfectly fine.

No matching enclosure

I honestly thought I designed the PCB around an enclosure, but apparently I didn’t.

Other than these problems, I could easily populate the PCB with the components. When I was soldering I already got the feeling I sought after for this project: Now, when I want to move a circuit to a permanent PCB, I no longer have to tediously solder all the bootstrap components and I could instead focus on the actual circuit I want to build around the ATmega.

Summary

The flaws I described above can be summed up to the following guidelines for future PCB design:

1. Measure all components: Using calipers or a ruler, measure the dimensions and pins of all components to confirm the compatibility with the design. This is especially true for components whose footprint is larger than the outermost leads (such as screw terminals).
2. Do a full signal trace of the design: Follow all traces and ensure that the signals (such as power or data) are present at the required connection points.
3. Print it out: Before submitting a design for production, print it out and lay the components on their respective place. Also cut it out and place it inside the intended enclosure (if applicable).

What's next

Even though there were some flaws in my first design I reckon I could’ve done a lot worse. After fixing the problems, the PCB worked and I’m overall happy with the result. I’m not going to implement a circuit with this batch (even though I have one in mind) since I failed to design it for an enclosure. In my mind, if a circuit is worth soldering for permanent use, it also deserves an enclosure. So I’ve selected an enclosure which I believe provides adequate space for small projects, the Kemo Electronic GEH KS 28. I selected this enclosure because it would allow for a piggyback PCB arrangement. I already have a PCB designed for it, but I’ll save all that for the next post.

The Fulree FW32D12A3 is a DC-DC converter that can convert from a range of input voltages to a stable 12V output. It can be found on eBay using the query “12V3A stabilizer” and purchased from multiple vendors.

The vendors often provide very sparse and superficial information, so I’ll try to fill in the gaps. I’ve used this converter successfully to stabilize an unstable 12V power supply so that a voltage-sensitive device could run off it.

Characteristics

Typical performance

Noise

The output of the power conditioner has irregular electrical noise of about 10 kHz with an amplitude of 1.82 V on its output.

Usage example

I came to this device because my new infotainment system in my car crashed every time I started the engine. That happens because the voltage drops to about 9 V when cranking the engine. So I put the Fulree inline with the constant power from the battery. To avoid cutting into the wiring of my car I ordered a ISO 10487 extension that I spliced the Fulree into.

I’ve been tinkering with Arduino stuff for quite a while now and sometimes I like to promote the project from the breadboard to the solder stage. However, that always meant getting some perfboard and before I could solder the electronics of the project, I’d first need to boilerplate the PCB by soldering an ATmega328P circuit. So I took this opportunity to finally learn PCB design and I implemented a boilerplate PCB that already has the ATmega328P onboard with perfboard around it.

After trying out some PCB design software, I settled on Fritzing. While it does have its quirks I find Fritzing to give just the right balance of simplicity and control, especially for a beginner. I designed the PCB straightaway in the PCB view and this is the design I came up with:

There is an LED connected to Pin 13 and a reset button. The empty corners are for mounting holes you can drill for your specific case.

I then used the suggested PCB manufacturer, Aisler, to order 3 PCBs. I’ll update this post once they arrive and I’ve soldered something on it. If this pilot is successful, I might extend it into a Permanente series with different processors and use cases. Also, you can check the project file out on GitHub.

Often, when I’m soldering a project I use a piggyback PCB solution to help save space inside enclosures. I made the following graphics to help with choosing the right enclosures, maybe this helps with your project too:

Variant 2 is for when soldering on perfboard where you have to push the plastic spacer of the male pin header all the way to the end in order to be able to solder on the side with the copper plating.

The following is an example assembly with an LCD, a push button, an LED and a brass standoff:

This was one of the rare days where it was actually snowing consistently instead of going back and forth between drizzle and snow. I went out in the evening and took these pictures. The atmosphere was wonderful; only a few cars were driving and it was completely silent otherwise.

I saw this project quite a while ago and I just had to build it myself: a desk clock using analog voltmeters to display the time! The build ended up being pretty straightforward; the voltmeters are DC 5V meters that I got on eBay with an Arduino driving them. They respond perfectly to PWM when using a 10 µF capacitor to smooth out the signal.

I got to thinking though when I put together the bill of materials that I didn't want to have a clock that I would need to set all the time. So I decided to use the DCF77 radio signal, which has been used to set all sorts of clocks since the early 70s. Thankfully, there are ready-made modules and also Arduino libraries so integrating it into the project was very easy.

Code