I recently saw a video for a ferro-fluid display, specifically a clock and then saw the $7000 price tag and thought, i'll give that a go myself instead (Link). This is very much in the preplanning stages (the fluid is on order as well as some magnet wire to make my own) and i thought id start tackling the hardest part for me, the logic and programming.

So my question is, is there a readily available 4 digit, 7 segment display driver or a homebrew solution that is a little more elegant than buying a generic LED 4x7 segment, ripping the top off and soldering leads to the individual LEDs?.

Ideally i was looking for something that can still make use of arduino libraries to keep the coding simple but was a little cheaper than this $40 shield (Link) while not having to go to an Arduino Mega to run the 28 segments individually. Basically i have plenty of spare time and enjoy soldering my own circuits so this is more of hobby experiment rather than a buy off the shelf components and just have it work the first time (things working correctly all the time is just boring, I'm a maintenance engineer, it would put me out of a job )

Thanks in advanced,
SimpleJoe

 

Are you looking for a 4 digit 7 segment display? Or how to write to it? When I use multiple 7 segments it is sent to them as a serial string with a chip to drive each individual digit. The 4 digit does not work that way and has 12 pins for the entire display instead of 10 pins for each digit. Are you looking for the chip to write to it?

https://www.ebay.com/itm/291521338665

 

Arduino 4-Digit 7-Segment LED Display https://www.electronicshub.org/arduino-4-digit-7-segment-led-display/

 

Are you looking for a 4 digit 7 segment display?

I'm not looking for the actual display itself, I'm just looking for something that is relatively easy to setup and to address all 28 segments of a 4 digit display. My plan is to then to somehow latch relays or transistors to run electromagnets to make a ferro fluid display like in my original post. Basically im looking for:

signal from an arduino with a DS3231 RTC (or equiv) >>> magic box >>> transistor array to energise any combination of the 4x7 segments (electromagnets)

I'd prefer not to have to control all 28 segments with separate pins from an arduino but i'm not knowledge enough in electronics to know what the type of circuit i am after is called. My current thoughts are 4 ICs with at least 7 outputs that latch so I can save which pins/electromagnets to turn on on the first segment, change to the 2nd IC and repeat the process, then reset all of the outputs to off and rewrite the new time every minute.

 

Look at the 2nd link. It uses a matrix/table for the 4 digit which is very different from how I typically do for multiple single-digit displays. Those have 10 pins, 2 for power and 8 for segments including the decimal. Plus a chip to drive each segment. The 4 digit uses 12 pins, 2 for power, 4 for transistors to turn on/off/select each digit and again 8 for every digit's LED segments. No serial bus strings or a driver chip since all segments are controlled in the Arduino code.

 

You could use 4 CD4511 ICs. these are 4 bit latches and BCD to 7 segment decoders. You could drive these using 8 I/O lines. 4 with data (Common to all 4 CD4511s) and 4 to pulse the clock pins on the the CD4511s. (One pin per IC.) I know nothing about ferro-fluid displays so I can't help with the driver circuit. If I wanted a large display I would use COB LED devices to make the segments of a large display

Les.

 

Have you done any programming of processors, if so what language
have you used ?

This is one approach, 8 digits shown, can be easy reduced to 4, would need external
current drivers for the display, at minimum in digit select lines. Like NPN transistor or
quad buffer. Also can be 12 or 14 segment if you wanted apha numeric capability.

Note how rest of chip resources, right hand window, unused, available for other tasks.
Those are onchip resources. Like A/D, DAC, OpAmps, Comparators, PWM, Timer,
Counter, Quaddec, Logic.....Drag and drop GUI tool, libraries for each onchip re-
source....



High end low cost board to do this $ 10, IDE and compiler free.

There are low end boards, $ 4, w/o debug. I would advise stay with $10
board until you get proficient with PSOC Creator, the IDE tool. Coding is
done in C.

Attached datasheet for onchip 7 segment component, a component is an onchip
resource. Most of the APIs you don't use in code as you set component up
by right clicking it and selecting its primary features, in this case like how
many digits, segments, etc.. The primary APIs used would be writes to display
something.


Regards, Dana.

 

Ideally i was looking for something that can still make use of arduino libraries to keep the coding simple but was a little cheaper than this $40 shield (Link) while not having to go to an Arduino Mega to run the 28 segments individually.

This showed up as the first search item: https://github.com/sparkfun/SevSeg

It mentioned needing 12 digital I/O's, but you should only need 11.

I find it more interesting to write the code myself. I learn more that way. I wrote code to drive a dual seven segment display. I used a timer interrupt to take care of updating the display so no latches were needed.

All code examples I saw used a byte in an array for each segment. That takes 112 bytes to display hexadecimal. I chose to use a bit for each segment and the lookup table was only 16 bytes.

The examples I saw all used digitalWrite to drive the segments individually. I used the port registers so I could change multiple segments at the same time.

Arduino Uno has only one I/O port with 8 bits, but they chose to use the first 2 for serial I/O; which seems lame brained to me. So I had to use portions of 2 ports; so twice as many writes to the ports were required.

 

Ok wow, where to start hahaha

You could use 4 CD4511 ICs. these are 4 bit latches and BCD to 7 segment decoders.

I will give them a look into, cheers

The 4 digit uses 12 pins, 2 for power, 4 for transistors to turn on/off/select each digit and again 8 for every digit's LED segments

ahhh, ok i missed your second reply, the circuit makes much more sense to me now, im assuming in this circuit its just quickly pulsing what needs to be shown in the 1st segment, switching to the second, and so forth to get it to display, the power state of the segments isn't latched? this may be a nice simple way around my problem, all depends on how the ferrofluid flows which brings me to:

I know nothing about ferro-fluid displays so I can't help with the driver circuit

Neither do I, I just saw a pretty thing and thought, huh, doesn't seem like $7000 worth of difficulty. I have no idea of the magnet strength required to move it around, I just like playing around with ideas, basically it all started with making my own word clock a couple years back, back when they were like $200-300 and not readily available on amazon. for this one personally i am thinking if i could "pump" the fluid to the top of the display with magnets and let it rain down like the waterfall code in the matrix and stick to the digit displays that would be pretty cool

Have you done any programming of processors, if so what language
have you used ?

Very minimal, i have done a small amount of coding in C++ and Python (enough to get me through an engineering degree) but that was 3+ years ago and will be little to no use now. The only processor programming i have done is with Arduinos and I am completely self taught which means the large majority of your comment went well over my head

I find it more interesting to write the code myself. I learn more that way.

I very much agree, thats why i mentioned in my second comment about the shield that seems to have 28 segment outputs, buy or downloading a predone circuit with code just seems a little too simple, this is a project to waste my time with and other than this forum post to get me at least heading in the right direction, I will most likely struggle with this over the next month or 5 in my own time

I used a timer interrupt to take care of updating the display so no latches were needed.

I will have to look into these again, i don't think i ever wrapped my head around interrupts

I used the port registers so I could change multiple segments at the same time.

Once again, never heard of port registers, looked it up and on the Arduino site itself it says "Generally speaking, doing this sort of thing is not a good idea. Why not? Here are a few reasons: The code is much more difficult for you to debug and maintain, and is a lot harder for other people to understand." I'm still not sure if this comment has scared me away or flared my hardheadedness, I;ll get back to you on this

Thanks again guys for all the help

 

I will have to look into these again, i don't think i ever wrapped my head around interrupts

They're pretty easy to use and examples are readily available. When you multiplex displays, you need to refresh at a couple hundred Hz to avoid flicker when the viewer's head moves.

Once again, never heard of port registers, looked it up and on the Arduino site itself it says "Generally speaking, doing this sort of thing is not a good idea.

Some of the port bits are "reserved". The low 2 bits of PORTD are reserved for serial I/O. The high 2 bits of PORTB are for the crystal oscillator (IIRC). You just need to use bit masks to only affect the bits you're using. If you're comfortable with bit operations, they aren't difficult to use or understand.

Using digitalWrite and digitalRead are easy, but inefficient.

 

The output of any 7-segment display system will take a LOT of extra circuits to drive that display. Better to start with what the display actually is, a dot-matrix. The display in the video is approximately 9 x 20 pixels, and each pixel is a *variable* electromagnet. this means that a simple latched-bit-per-pixel driving system will not work. Note that the only way to get fluid to the top bar of a "7" is to walk it up there one pixel at a time.

Now that someone has shown that the thing is possible, my guess is many months to reverse-engineer and reproduce the physical display, more months for the driving electronics, a year to finalize the driving software, and I-Don't-Know-How-Long to develop the wifi interface and user app. You're not just translating 10 images to their equivalent pixels, you're creating a graphics display language.

$7000? - cheap.

ak

 

If you want we can tackle my post, your questions, one by one. There is a
set of short videos you can look at, show you just how easy it is to work
with a GUI drag and drop tool. A whole lot nicer than traditional IDEs. In fact
you can actually do some simple designs codeless. I can make up an example
if you are interested.

On your other question.

Arduino port registers - https://www.arduino.cc/en/Reference/PortManipulation


Regards, Dana.

 

I agree with AK and did some reading about it this morning. It is more like a graphical screen than a 7-segment display.

A single character by my count is about 14 "dots" (6 across and 8 vertical):


That does not include the "walking up" shown well in this video: https://weather.com/science/video/clock-uses-magnetic-ferrofluid-to-display-time This study used currents of 100 mA or more and field strengths in the mT range:
https://www.sciencedirect.com/scien...id=1-s2.0-S1875389210007467-main.pdf&_valck=1

Each dot must remain energized (unlike LCD), but I don't think the frequency needs to be as high as is used for LED's, because the fluid responds relatively slowly in comparison.

Rather than worrying about how to access the pixels, I would begin by determining how much current is needed for an effective pixel and what size the magnet needs to be.

 

Once again, never heard of port registers, looked it up and on the Arduino site itself it says "Generally speaking, doing this sort of thing is not a good idea. Why not? Here are a few reasons: The code is much more difficult for you to debug and maintain, and is a lot harder for other people to understand." I'm still not sure if this comment has scared me away or flared my hardheadedness, I;ll get back to you on this

This is standard fare in embedded work, setting up GPIO characteristics.

As far as other people understanding, a good programmer comments his code
as a form of documenting what is going on. If thats done properly, and given
most embedded C is fairly straightforward (I'll get some bullets on that) its
not that difficult to follow.

On the external driving chips to handle current, if the segment current is in
the range of 5 - 10 ma no segment driver is needed, just direct drive from
a PSOC chip. Its the digit drivers that handle the sum of all segments that
needs most help. Thats either a quad buffer in your case or just NPNs and
some R's. Note an Arduino can handle segment drive directly from the pin,
20 mA kind of range.


Regards, Dana.

 

After the Three-S ritual, some more thoughts -

Each electromagnet must have bipolar energization. That is, the pole face facing the screen must be able to go from strong north to strong south *continuously*. OK, it can be driven with the output of a D/A converter, but the steps must be pretty small for the smoothness of the animation in the video.

A front page video demo should have appealing production values, but they just get in the way of reverse engineering. This video is better for evaluating the display as a whole:

http://www.ferrolic.com/where-digital-meets-nature/

Go to 1:10 and watch the movement of the two pixels leaning in for a kiss. That is hard. Based on the name, the gunk that is moving is an iron formulation ground very fine and suspended in a fluid. The mass of each blob goes a long way to smoothing out any quantizing steps in the driving waveforms, but that slow kiss shows very fine control over the associated magnetic fields. AND, the fields must be bipolar-capable or else the two blobs would repel. The driving software just got a lot harder.

Also, there is no law that says 100% of the backing electronics must be contained within the display. For all we know, there could be a 1 kW switching power supply, and 200 10-amp bipolar linear drivers in a box the size of a microwave oven, and a multi-core PC with a wowzer graphics board banging away in the background.

Or not. The max power requirement is set by the maximum number of pixels energized at least partially at the same time. For something like a 7-segment clock display, that is way less than 25% of the total. Still, converting motion vectors to raster graphics is very calc-heavy programming. In the 50's and 60's this was PhD-level government-funded research, while today it is in a well-rounded C++ library. After 60 years of development the concepts are very well understood, but this is *not* entry-level programming.

https://en.wikipedia.org/wiki/Charles_Csuri#Digital_art
https://en.wikipedia.org/wiki/Cranston/Csuri_Productions
https://accad.osu.edu/

ak

 

my guess is many months to reverse-engineer and reproduce the physical display, more months for the driving electronics, a year to finalize the driving software, and I-Don't-Know-How-Long to develop the wifi interface and user app. You're not just translating 10 images to their equivalent pixels, you're creating a graphics display language.

$7000? - cheap.

Where is your sense of adventure? Don't get me wrong, for how brilliant it works and looks I can easily see a prototype like this costing that much but my aim is to take this great design and make it a little more accessible to the home player. My intentions are to go as simple as possible that's why i decided to start with a clock (sorry, looking back i don't think i specifically stated this), something that is a little more advanced than moving a blob between 2 dots (however, obviously this will be my first step as a proof of concept and wrapping my head around how it behaves) but not as intense as full dot matrix display that is wifi enabled picture frame that can create an accurate representation of the Mona Lisa. This is more a thought project and something to sink my time into for me rather than anything else, if a guy could recreate the design in a mine site room in the middle of Australia with a couple of meters of magnet wire and a can do attitude, well... i wouldn't need to be sitting in a mine site room in the middle of Australia .

I agree with AK and did some reading about it this morning. It is more like a graphical screen than a 7-segment display.

Yeah, as above, I never explicitly said I am just in it to make a clock (atleast at first), that one is on me.

I would begin by determining how much current is needed for an effective pixel and what size the magnet needs to be.

That's is all on hold as i wait for the parts but definitely something I've had in my mind for a while and will obviously be my first step towards actually creating this thing. But once i have an idea I usually fixate on it thinking of all the possible designs and problems to overcome so while I can't rush the postman I can at least get the ball rolling on possible driver circuitry, at least in a theoretical sense.

Go to 1:10 and watch the movement of the two pixels leaning in for a kiss. That is hard.

Yeah, my bad again, that sort of control is well out of the scope of what i am thinking, my plan at the moment is to have the magnets latch on to correspond with the time and have the ferrofluid trickle down from the top (think Like the matrix code) and stick to the powered on segments, this will require a pretty accurate amount of fluid so the upper segments grow too large and "drip" down to the lower to get a full display but that is future Joe's problem.

Each electromagnet must have bipolar energization. That is, the pole face facing the screen must be able to go from strong north to strong south *continuously*

I had thought about this, i need to play with some more magnets I can't actually wrap my head around if the two blobs would repel or join and then split. My next thought was low voltage AC magnets (50Hz may cause it to "breathe" and I might actually like that more) then instead but AC is very much a dark art to me and I feel dirty even having such thoughts, i'm going to sit in the corner and think about what i have done

Once again thanks for all the help, super constructive stuff,

SimpleJoe