Comments (22)
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!
from exixe.
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.
from exixe.
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.
from exixe.
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.
from exixe.
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?
from exixe.
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?
from exixe.
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.
from exixe.
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.
from exixe.
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);
}
from exixe.
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.
from exixe.
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
from exixe.
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?
from exixe.
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).
from exixe.
hi RandomNameHere! What microcontroller board are you using?
from exixe.
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.
from exixe.
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.
from exixe.
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.
from exixe.
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.
from exixe.
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!
from exixe.
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?
20220213_122847.mov
from exixe.
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.
from exixe.
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.
from exixe.
Related Issues (17)
- LED does not stay lit HOT 6
- Windows 10 & STM32 ST-LINK
- Exixe14 BOM not matching PCB HOT 8
- Overdrive doesn't seem to do anything HOT 1
- Unable to completely turn of the LED HOT 1
- Mounting methods HOT 2
- Crossfade issue on ESP8266 HOT 2
- SPI pins HOT 17
- Random blinking numbers and inconsistent LED behaviour HOT 7
- Arduino library: Initialising multiple tubes doesn't seem to work HOT 2
- The exixe 2018 boards not working HOT 13
- sourcing STM32F042K6T6 HOT 1
- Created and assembled board, connected to ST Link V2 HOT 2
- Arduino library: memset not defined HOT 4
- The MISO and MOSI pins are the wrong way around on the getting started page HOT 3
- exixe12_bom different capacitor values HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from exixe.