[Dr_C]

   

Catering for all tastes - here is an image showing dimensions in mm.

 

[Dr_C]

Now some thinking aloud…

I tried to make the display pcb as small as possible with the result that it measures 14.5mm x 12.5mm.

This includes the two display modules on one side and the driver chip (ATtiny3226), bias resistors, 6 way FFC socket and six separate solder points on the other side.

The result is a small board which fits nicely behind the windscreen.

But how should it be firmly attached to the body-shell?

My thinking is maybe a second pcb with no electronic circuitry what-so-ever… instead, six solder points in a row that mate up with the six solder points on the display board. Joining wire can then form a rigid but adjustable hinge. After adjustment to the correct angle the secondary board can the be hot glued onto the underside of the vehicle roof.

A ‘two board’ solution might work nicely!

c

[Dr_C]

   

Here is the proposed ‘two-board’ solution for simple mounting of the 2-digit windscreen display.

The board will be assembled as a single unit, the six hinge wires added, and then the two side-tabs will be snapped away. The hinge angle can then be adjusted to match the windscreen angle of the car. The  upper section of the assembly is then hot-glued to the underside of the car’s roof.

This version of the main display board includes the following four in-car decoder connection options:

1/ ID reading from IR LED signal (current preference).
2/ ID reading from decoder via uart rx/tx
3/ ID reading from decoder via SPI bus
4/ ID reading from decoder via I2C bus

Meanwhile, the ATtiny is programmed via a single wire UPDI interface so a further option could be to hard-code the display via UPDI.

Next we need to see a race pack of AMGs on a starting grid with their IDs displayed on their respective windscreens.

:)

c

[Dr_C]

Two versions now in prototype PCB production.

They are basically the same except:

One version is for IR LED signal read plus uart plus SPI bus options.


The other version is for IR LED signal read plus the I2C bus option.

c

[Dr_C]

   

Spot the difference?

[Dr_C]

Some more details…

First the reason why there are multiple signal options:

1/ the IR LED signal input enables the ID display to be driven directly by SSD, D132 or SCX-A decoders. In each case the IR LED signal carries ID information which is decoded to provide the ID display read-out. This automatically ensures the ID display read-out matches the decoder ID.

2/ the UART signal enables the ID read-out to be programmed with the appropriate ID display read-out. This approach is manual but will enable the ID displays to be used in conjunction with O2 wireless decoders. Care will be required to ensure the display read-out is programmed over UART to match the decoder ID.

3/ the I2C and SPI options require a serial data-bus interface with the decoder which can enable additional display functions as well as automatic direct ID read-out. This makes the two digit displays very versatile with applications well beyond simple screen displays. That said, these are fast industry standard serial data bus configurations and will work extremely well for decoder to windscreen read-out applications. All my DPR decoder designs (for SSD and wireless) over the past three years have included I2C/SPI data-bus connectivity via a flat flexible cable (FFC) interface.

And, just to add, hardware using all of these signal methods is in development i.e. included in the two board designs shown above.

Hope all of above makes good sense.

c

[Dr_C]

   

While I wait for the two-part hinged PCBs to arrive I can press on with the display firmware. This is programmed using a UPDI (universal programming and debug interface) accessed via the FFC port.

The photo shows the early prototype hardware as per the 3D image shown in post #1 - a perfect platform for developing the firmware.

Six of these prototype boards will be fitted alongside SSD decoders into a group of Scalextric GT3 cars.

c

[Dr_C]

The microcontroller at the core of the two digit windscreen displays as mentioned earlier is an ATtiny3226. Here it is being used as a simple display driver, interpreting the incoming communications signals as required. For this application I am using the VQFN-20 package which measures 3mm x 3mm. It’s my favourite 8bit microcontroller.

I also use these controllers alongside the nRF24L01+ rf module for wireless throttle controllers. It’s a versatile and flexible little microcontroller with an impressive specification.

I use a similar device(ATtiny3224) to upgrade SSD lane changers and plan to fit some as annupgrade for SSD in-car decoders.

A great little device and easy to program too.

c

[Dr_C]

x6

   

[Dr_C]

The above hardware is now tested for fitment into a grid of six SSD GT3s. That said, all testing so far has been with the displays sitting on the test bench - not as yet in vehicles running at 1-10m/s.

It’s going to be interesting learning how readable these 5mm tall two digit displays are when cars are in motion.

Also, will the readability results be different for day-time and night-time driving? Likely yes - but let’s see :)

In this design all LED segments are either on or off (except when changing of course) i.e. the design avoids any type of display segment scanning. This should help with readability while the car is in motion.

c