Inconsistent behavior with multiple exixe

[poitch]

I'm trying to drive 4 nixie tubes (with the goal of driving 6 for a clock)

I'm seeing inconsistent behavior. I see either 0, 1, 2 or 3 tubes changing digits. Even when 2 tubes are running, sometimes a digit might not flip.

Based on the documentation, I'm guessing this might be due to a lack of power but the 4 exixe are getting the 3.3V from my power supply directly (3.3V rated at 800mA max) I do have a GPS module connected to the same supply and it is able to run and get a fix.

My code currently stores the last digit and calls show_digit when the digit changes for that particular tube

if (digit != tube_digit) {
    tube.clear();
    tube.show_digit(digit, 127, 0);
    tube_digit = digit;
}

tube.spi_init() is only called once in setup()

If I use the first 2 exixe for seconds then I am able to see them count up based on GPS time. But the next 2 tubes which are hooked up to minutes aren't showing anything, even though I can see in the logs that I am calling show_digit.

I had followed the getting started guide and tested tubes and ran the LED test on the exixe board by themselves.

Any idea on how to debug the issue here? Thank you

[dekuNukem]

There are a few things that I can think of. First off, check to make sure everything shares the same GND. There might be some noise on the SPI line, so maybe try calling tube.show_digit() multiple times in a row and see if it helps. Also, you don't need to call tube.clear() every time to update the tube, so maybe try leaving it out for now.

Also, only as a last resort, sometimes breadboards have dead holes in them, so try shifting the components around and see if it helps. This is unlikely, but it did happen to another user!

[poitch]

I ran into the GND issue while running the LED test yesterday.

I just rewired everything from scratch and with only 2 tubes (no GPS) and made sure the ground was common between the Nano, the exixe, and the power supply.

I experimented some more and things are really bizarre at this point. I can get one tube to work really well when I connect SCK, MOSI, MISO, and CS but as soon as I remove MISO it stops working which does not make any sense.

If I ignore the fact that I shouldn't need MISO and add a second tube using the 4 lines (shared SCK, MOSI, MISO + 2 separate CS) then nothing works anymore. I even tried the multiple tube.show_digit() calls and removed tube.clear() that did not change anything.

I tried a few combinations and it seems that as soon as I plug in SCK or MOSI then the first tube stops working.

I have tried 2 different Nanos (unfortunately burnt one out), tried different holes in the breadboard, different jumper cables to no avail.

[dekuNukem]

This is a bit bizarre indeed. It looks like the power supply board is providing both 170V and 3.3V, can you link the page of where you bought it from? I'd like to read about it a bit.

Other than that, I would suggest start as simple as possible with 1 exixe module, no high-voltage, and just the LED test in the example. If that works fine, expand the LED test to two modules and see if it works consistantly. It would also help if you have a oscilloscopeor logic analyser to see what's going on on the SPI line.

[poitch]

I bought the power supply from ebay, but here is the official website.

The 3.3V is actually coming from a DC-DC conversion from the 5V line. 5V is its own converter.

I have ordered a logic analyzer so I could see what was going on on the SPI lines.

[poitch]

Tried again the basic LED test with one exixe only. Both using the 3.3V power supply and the Arduino Nano 3.3V. I did change the sequence to be tube.set_led(127, 0, 127); delay(500); tube.clear(); delay(500);

I cannot get it to work consistently unless I hook up MISO.

It seems like when I fiddle around with the SCK cable I get the LED to light up sometimes, and sometimes it gets purple but in most cases, it is the wrong color. That seems to indicate some noise on the SCK line.

I'm curious though, what is MISO hooked up internally in the exixe to cause it to stabilize so well? I'm wondering if I'm still not sharing GND properly for some reason, but since I have the same problem when using the Arduino's power that seems unlikely.

I've tried a new breadboard and new cables to no avail.

What gauge would you recommend for the cables?

[dekuNukem]

The MISO is indeed connected to the microcontroller on the exixe module, but its data is not used.

I went over the source code of the exixe modules, and it might be helpful that you know that when exixe receives a invalid SPI command, it will reset itself and start fresh. You can see the code here. So if the SPI line is very noisy for some reason, the module might reset a lot and not do what it is supposed to do.

with the basic LED test, does the stability issue happen with all 4 exixe modules, or does it happen with just one of them?

[poitch]

Yes, the behavior is the same on the 4 exixe.

I don't think I get the reset as I can see random LED colors instead of purple. Maybe some noise on the MOSI line as well as the SCK line. Repeating the calls to tube.set_led() does not change anything though.

[dekuNukem]

Maybe try just wire the exixe module directly to the nano without using breadboards? Using the arduino 3.3V for power just for the LED test, and see if it works consistantly.

Also, it would be great if you can post the testing code here so I can see if there are potential problems. You can compress the entire arduino project into one .zip file, and upload it into google drive and share a link.

[poitch]

I have tried quite many things over the last few days (2 brands of breadboards, 2 brands of wiring, 2 types of Arduinos for a total of 4 of them, single tube, multi-tube) I have to order some female jumper cable to try direct wiring.

Introducing the logic analyzer in the single tube test would usually make things work, and at times would make a 4 tube system work depending on where I would put the probes.

Looking at the logic analyzer and the decoded SPI messages, I see a lot of noise. Very often, I see 0xAA only once out of many messages, and even when I get 0xAA, the body is usually incorrect. I made sure my logic analyzer was sampling at a multiple of 8MHz and that it was decoding MSB instead of LSB (I was getting 0x55 at first)

I also did try the bare bone example as well to make sure I would only send the one message on interval. The logic analyzer would show garbled data most of the time and a small percentage of "correct" messages. Even the correct messages would usually get a 0x00 on some of the digit bytes instead of 0x80, but the RBG fields would be correct.

I have tried with the probe at the output of Arduino directly as well as along the lines.

With 6 tubes, I usually get only 0x00s on the MOSI line by the 5th tube.

I tried to mess around with the SPI clock (lowered to 4MHz) to no avail.

The code is the one from your example, so I'm not sure there is a lot of value for me to upload what I downloaded from you :)

Here is one example where I tried to have the 6 tubes connected and do a simple counter with nothing else, and as usual saw only some digits light up here and there. As you can imagine with garbled SPI messages, the results are completely random and unpredictable.

#include <exixe.h>

#define CS1 10
#define CS2 9
#define CS3 8
#define CS4 7
#define CS5 6
#define CS6 5

exixe tube1 = exixe(CS1);
exixe tube2 = exixe(CS2);
exixe tube3 = exixe(CS3);
exixe tube4 = exixe(CS4);
exixe tube5 = exixe(CS5);
exixe tube6 = exixe(CS6);

void setup() {
  tube1.spi_init();
  tube1.clear();
  tube1.show_digit(0, 127, 0);
  
  tube2.clear();
  tube2.show_digit(0, 127, 0);
  
  tube3.clear();
  tube3.show_digit(0, 127, 0);
  
  tube4.clear();
  tube4.show_digit(0, 127, 0);
  
  tube5.clear();
  tube5.show_digit(0, 127, 0);
  
  tube6.clear();
  tube6.show_digit(0, 127, 0);
}

uint16_t count;

void loop() {
  count = (count + 1) % 100000;
  uint8_t v = (count / 100000) % 10;
  tube1.show_digit(v, 127, 0);  

  v = (count / 10000) % 10;
  tube2.show_digit(v, 127, 0);  

  v = (count / 1000) % 10;
  tube3.show_digit(v, 127, 0);

  v = (count / 100) % 10;
  tube4.show_digit(v, 127, 0);  
  
  v = (count / 10) % 10;
  tube5.show_digit(v, 127, 0);  

  v = (count / 1) % 10;
  tube6.show_digit(v, 127, 0);  
  
  delay(300);
}

[dekuNukem]

If attaching a probe changes the stability of the system, then it does seem like a noise issue. Is the SPI output correct straight from the Arduino pins when no exixe is connected? The logic analyzer sample rate doesn't haveto be multiples of SPI clock, just more than twice as fast is enough.

It would be great if you can post a screenshot of the logic analyzer capture of the problem SPI waveforms too.

I'm sure you have seen it, but just in case, there is a sample correct SPI waveform capture in this guide.

[poitch]

Yes, I had seen the capture which was really helpful in configuring my own logic analyzer.

See attached a capture straight out of the Arduino's pins. Arduino was just on a mat with nothing else plugged in. Only the USB to my computer and the probes of the logic analyzer on the header pins.

As you can see most messages aren't what they are supposed to be and eventually the header gets garbled and thus missed.

In this particular capture, 3 consecutive messages looked like this: 0xAA 0x80 0x80 0x80 0x80 0x80 0x80 0x00 0x80 0x80 0x80 0x80 0x00 0xFF 0x80 0xFF 0xAA 0x80 0x80 0x00 0x80 0x80 0x00 0x80 0x80 0x80 0x00 0x80 0x80 0xFF 0x01 0xFF 0x01 0x01 0x01 0x01 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0xFF 0x01 0xFF

Here is the code that generated those captures:

#include <SPI.h>
#define SPI_BUF_SIZE 16

uint8_t spi_buf[SPI_BUF_SIZE];
// change this to the cs pin you're using

const int slaveSelectPin = 7;

void setup() {
  pinMode(slaveSelectPin, OUTPUT);
  digitalWrite(slaveSelectPin, HIGH);

  SPI.begin();
  // 8MHz SCLK, MSB first, SPI mode 0
  SPI.beginTransaction(SPISettings(8000000, MSBFIRST, SPI_MODE0));

  spi_buf[0] = 0xaa; // first byte, header
  spi_buf[13] = 0x80 | 127; // red LED full brightness
  spi_buf[14] = 0x80 | 0; // green LED off
  spi_buf[15] = 0x80 | 127; // blue LED full brightness

}

void loop() {
  // cs low
  digitalWrite(slaveSelectPin, LOW);
  // send 16 byte command
  for (int i = 0; i < SPI_BUF_SIZE; ++i)
    SPI.transfer(spi_buf[i]);
  // cs high
  digitalWrite(slaveSelectPin, HIGH);

  delay(200);
}

The full sequence of a capture which shows how some message are correct and a lot aren't: 2020-08-27_21-45-17.csv.zip

[dekuNukem]

It looks like you have found the issue. If the SPI data is corrupted straight out of the arduino, then it's not suprising that exixe isn't working consistently as a result.

It is very strange to see SPI broken like this. The MOSI data is supposed to be valid and stable on the rising clock edge, so maybe check if that is the case.

You mentioned that you have tried a few different arduinos. Are they all like this?

[RandomNameHere]

Hmm, I seem to have the exact same issue. No problems with single tubes at all, but running any more than one will cause numbers to not refresh, completely go away, or even have 2 numbers on the same tube. I don't understand the SPI data is getting corrupted (assuming that's the issue).

[dekuNukem]

hi RandomNameHere! What microcontroller board are you using?

[RandomNameHere]

Hey, I'm using a pro micro. Although I used an oscilloscope and figured the data isn't corrupt or anything. It seems that 3.3 volts isn't enough to consistently power multiple exixe modules. This is extremely strange to me. I am however using a linear voltage regulator to drop the input current down to 3.3 volts. The actual power source for the device is a 5 volt wall wart. No issues there and the input voltage is consistent. I don't see how the modules are requiring a higher voltage.

[dekuNukem]

Can you post a photo of your setup?

I think I might have a pro micro somewhere too, and I'll try it out tomorrow if i can find it.

[RandomNameHere]

Oh boy, I think I'm a huge idiot. I realized that I didn't run the CS lines through voltage regulators which was causing the exixe's to trigger off clock. I'm fixing it now and I don't think there should be issues otherwise.

[User12512]

Sorry to wake this thread up after two years, but I'm having this exact issue. Random digits and backlight LED settings flashing only occasionally instead of the digit that was connected. I'm attempting to power 6 boards (currently have 3 rigged up at the moment) and using an LM2596 buck converter to power them with sufficient current. My ground is common between all components. From what I've gathered, this is an issue with the SPI lines but I don't see how that happens. RandomNameHere said having voltage regulators on each CS line would fix the problem, but would that be necessary? I just have digital pins connected directly to the CS pins on each exixe board.

[dekuNukem]

Hi there! Sorry about missing the notification. Let's start simple with only one exixe module. Does that work reliability? Can you also let me know which microcontroller you're using, thanks!

[User12512]

Hi there! Sorry about missing the notification. Let's start simple with only one exixe module. Does that work reliability? Can you also let me know which microcontroller you're using, thanks!

Ok. One exixe works perfectly, but at two and up I get what others have mentioned - random digits and at times more than one illuminated inside a single tube. The backlight also goes from off to blue at random, even though in my code I commanded it to be dim. I'm using a single Arduino Uno to make the digits go from 00 through 99. Here's what that looks like. I'm not trying to light the third tube in this video, by the way. Every 500 ms there's a state change, and the boards seem to use that opportunity to display whatever they want. It does happen on time, however. I'm thinking garbled SPI. Thoughts?

https://user-images.githubusercontent.com/99311123/153782081-1ee7174f-7903-4f69-8bc3-87e1d8984625.mov

[dekuNukem]

It could be a power issue, or even bad holes on the breadboard.

I wrote some suggestions at the troubleshooting section, maybe try some of them out and see if it improves.

[User12512]

Hey, sorry for such a long delay. I'm going ahead with putting together the module I'm trying to build, it's going to be entirely solder joints and prototyping board with header pins just so nothing's absolutely permanent. I'll let you know if it doesn't work after that.