I would also look at the suggestions for 32 bit transfers and the order of
control over the LE signals that Paul has suggested - I will most certainly
be doing this when I next visit my code. I know that if its not broken, one
shouldn't try to fix it but just because I cant see that its not
Hi Richard,
Thank you for the insight on the use of the CD40109. I've ordered a couple
Texas Instrument DIP versions off ebay. Once I get them I'll pursue putting
some SPI code together using your example you posted earlier.
As you mentioned, at the moment I'm getting away with using 5v logic
Thank you for the confirmation of the 32 bit SPI, Paul had mentioned this
to me previously but I had not pursued it as what I had was working -
similarly for the handling of the LE line - I noticed no immediately
visible difference when moving the dropping of LE to after the SPI Write
commands
Richard, I'm using the 32-bit SPI-write for my most recent ESP32 based
clock. I'm saving the data for all six tubes and the colons in a single
64-bit variable (uint64_t), so sending out the data can be done with just
four lines of code:
digitalWrite(SS, LOW);
SPI.write32(nixData);
An ESP8266 / Wemos device runs at 3v3 logic levels, the HV5622
specification indicates that it likes to run at 12V logic levels so there
needs to be some conversion between the two for reliable operation.
The spec sheet for the HV5622 clearly states that the logic supply voltage
should be
That code is for the HV5523 by the way. Make sure to pay attention to the
truth table in the HV5522/5622 datasheet to know if data is clocked in on
the rising edge or falling edge of the clock signal.
btw the HV5522/5622 are nearly identical, only difference is the 5522
shifts in a
If you're trying to shift at any decent frequency (which would be
desirable for a smooth crossfade event) then I would not use 'digitalwrite'
as it is an arduino function which takes a lot of processor time to simply
change an I/O to high or low logic level. Hardware SPI is #1, but I found
that a
There is a 32 bit shift out, at least on ESP platforms.
You aren’t limited to specific pins on the ESP8266
I am pretty sure that for these chips you should move this line
> digitalWrite(LEpin, LOW);
To just before this line:
> digitalWrite(LEpin, HIGH);
> On Jul 22, 2020, at 10:28 AM,
For the SPI I have the following in my sketch:
#include
In setup:
// set up SPI
SPI.begin();
SPI.setFrequency(10);
SPI.setBitOrder(MSBFIRST);
SPI.setDataMode(SPI_MODE1);
//set outputs for SPI
pinMode(LEpin, OUTPUT);
Then, I have the following code that, in my case, is
Hello, yes I can help here, I'll reply when I get back to base but it was actually a fairly simple transition from shiftout to SPI transfer, back to you within 24hrs.RichardSent from my Huawei phone Original message From: Owen Crawford Date: Wed, 22 Jul 2020, 08:38To: neonixie-l
Hi Richard,
You mentioned you have a working solution to digit fading?
I am pretty much in the position with designing a Nixie clock using the
HV5622 chips. I have worked out most of the PCB design and got a few
prototypes boards made up.
The HV5622 chips are in series and I've managed to make
There's another way of dimming/fading described in this thread with source
code on Github - not mine, just remembered it.
https://groups.google.com/forum/#!searchin/neonixie-l/fading$20table%7Csort:date/neonixie-l/bh7kymv2xQA/MogsmOnHAgAJ
/Martin
--
You received this message because you are
I have a working solution to fade between digits which is mostly there,
just a little fine tuning with timings and perhaps some additional fade
steps but it's all good.
Thank you for all your help.
Richard
On Friday, 1 May 2020 04:56:06 UTC+1, Richard Scales wrote:
>
> Hello everyone,
>
> I am
That is great news thank you.
I'm starting small and building up, still reeling with excitement having
just produced a square wave at 250Hz.
Richard
On Sat, 2 May 2020, 11:58 Paul Andrews, wrote:
> The idea is correct, and your calculations look correct. I wouldn’t worry
> about the exact
The idea is correct, and your calculations look correct. I wouldn’t worry about
the exact timing, you can adjust that once you have it basically working.
> On May 2, 2020, at 12:21 AM, Richard Scales wrote:
>
>
> Further thinking: - perhaps I don't need all those levels, perhaps just 5
>
Further thinking: - perhaps I don't need all those levels, perhaps just 5
levels of fade might be appropriate - in which case the outer loop is 5
iterations, each one 40mS if the overall fade process is to last 200mS,
therefore the inner loop has to last for 40mS.
The inner loop emulating a
I can see the concept just ahead of me - I'm still working out how to grasp
it though!
If the fading process is set to run over say - 200mS , the fade completes
after 200mS and would therefore leave the static displayed digit (for the
'seconds') displayed for 800mS before the fade to the next
Thank you, I'll think more on this and create a test environment.
Thank you for your guidance.
Richard
On Fri, 1 May 2020, 15:36 Paul Andrews, wrote:
> You run them in parallel. In this scenario the faders don’t control the
> digits, your loop does that. It just reads the on/off state of the
You run them in parallel. In this scenario the faders don’t control the digits,
your loop does that. It just reads the on/off state of the faders and figures
out if that means a digit is on or off. Then it increments the fader and
figures out if it also needs to adjust how long the ‘on’ period
Thank you very much for that, I'll keep reading it until I fully understand
(could be some time). Are these three faders running in parallel or in
series?
I think I can see how this might work if they are in parallel. Ie, assuming
100 ticks per cycle, for each tick, check the status of each fader,
I do all the fading in software. Imagine you are running three faders. One
for overall brightness, one for fading in and one for fading out. When
you’re figuring out if a digit is one you say:
1. For static digits, if the brightness fader is on, then that digit is on,
otherwise it is off.
2.
Just refining my query:
Having thought about this a little more and only assuming that my pseudo
code example is anywhere near correct, would anyone be able to suggest what
the relative timings might be for the period that the static digits are
displayed and the range of periods for the fading
I have an 8-tube clock with b7971's and whenever I find the time... I will
add a software routine that calculates which segments will change, and
instead of changing them all at-once, they will be split into a few groups
that change every 50-100msec. I think it would be too distractive for
23 matches
Mail list logo
