Component side, lots of 5 V CMOS, processor, optical interfaces:
Would make a nice Merry Christmas running text.
Anybody from .NL used these? Looks like RS232 over optical to me, but no idea of baudrate or protocol. I have the circuit diagrams, but there is no component numbering on the board. Board initilalizes, some rows come on for a second, then goes black (cls).
I can send some logc level serial data into the on board micro processor past the optical interface.
Now THERE is some project. :-) Could use it for clock, email on the wall... temperature.... Could be from busses or train stations.
On a sunny day (Thu, 12 Dec 2013 19:55:36 -0500) it happened Martin Riddle wrote in :
Yea, I did some googling, and there is a huge blog by nl people (in Dutch) who got it working and somebody cracked the codes.
19.50.18.jpg etc etc erc
Its a 16 mbits serial peculiar link, so what I thought was a processor turns out to be a CPLD, and some have removed that chip and drive the shift registers (CMOS) directly. Some drive it with an Arduino, some with a PIC, some with ARM, what not. Seems to be in popular demand, bigger ones exist too. Found it late last night, will have to read it again to see if I can drive it with that clock, or connect a Raspberry (they have done that too) GPIO to the shift registers, still some days to christmass. Google is a great help.
On a sunny day (Fri, 13 Dec 2013 08:37:01 -0500) it happened Martin Riddle wrote in :
I just removed the CPLD (dremel), and now I can make nice patterns by touching the shift register inputs. I will look up the Raspberry Pi GPIO pins that will most conveniently connect to shift register clock, data, enable, and latch, so I can plug a Raspi into it (or PIC maybe later) will be 3.3 to 5 V for the Raspi. The rest, as they say, is software (and most already written by others). Uses a lot of current..... Good thing I have some 7.5 V 20 A supplies from the same source. Mine are yellow, and VERY bright.
Probably. Usually slave SPI peripherals do not care much about the timing the master uses, so long as it is not too fast (enough setup time, slow enough clock). If you were making a slave you might need hardware.
On a sunny day (Fri, 13 Dec 2013 15:50:15 -0500) it happened Spehro Pefhany wrote in :
Yes, the problem here is that the display units are 7x7, and addressed row by row, and that 34 x, so a loop in a loop x 8 for bits This causes flicker in the display if not done fast enough. Just wonder if GPIO on Raspberry is fast enough.
BTW in regards to your other post about tires, I have such a small compressor, I use it as 12V backup (it has a cigarette lighter connector), and also has a LED lamp, charges again from a wall wart. You can fill about 2 tires from one charge, This one is showing some signs of wear, has a good pressure meter too. My experience with gas station tire fillers machines?? is that sometimes those do not show the correct PSI, this unit does. I once almost exploded a spare tire while filling it at a gas station, noticed it just in time and let the air out again.
All our cars have gauges in the glove compartment.. the digital ones are pretty cheap, but I think the round type with a needle are better. The worst are the ones with the graduated rod that pokes out depending on pressure. Hard to read the graduations while freezing in the dark with snow swirling all around.
As a kid, I actually exploded a tube on a bike tire at a gas station. Very traumatic.
Best regards, Spehro Pefhany
"it's the network..." "The Journey is the reward"
firstname.lastname@example.org Info for manufacturers: http://www.trexon.com
On a sunny day (Thu, 12 Dec 2013 19:32:40 GMT) it happened Jan Panteltje wrote in :
Some soldering and coding later. It works:
The interface that replaces the CPLD:
The hardware mod, I used thin wires, these CPLD pads come of easy:
That little screwed on board has a header the Raspberry Pi cable from the GPIO fits in.
All this wokrs OK, but if the raspi does other things there is some flicker in the display, as there is more delay between refreshes (it is multplexed).
Sphere you were right, I needed to slow down the code to get the setup times, at high speeds the Raspi cannot even drive all thode CMOS inputs in parallel, All this asks for a PIC with a bit of power on the outputs.
This is just test code, I borrowed somebody elses char set (7x7), th structure allocation is not correct in the delay routine, the scan lines in the hardware seem mixed up, so I changed that, characters need to go in in reverse... LOL
On a sunny day (Sat, 14 Dec 2013 19:35:30 GMT) it happened Jan Panteltje wrote in :
Now that I have control over it, I finally started thinking about this display.
The first thing that bugged me was that what is called the RES_RED signal. It needed to be always one in MY software.
Digging in the circuit diagram I found it is nothing else than OE of the shift register latches, and putting it low, blanks the display because the darlingtons it drives have a resistor to ground, and OE low (output enable low is output tri state) then causes a 0V, pixel out. Related to that is the fact that if the software is not running, OE can be high (or low), but if high, and no scanning takes place, the poor pixels in the matrix displays are on 100% of the time, looking at the current consumption those LEDs may live short, and that happens for example during running boot, testing, etc. So I designed a small 1 transistor circuit that puts OE low when it sees no scanning:
that, on the right, is actually an AC detector, when the scan pulse is present the transistor conducts every now and then, and the RC networks charges to almost the 5 V supply. When the scanning is not present the RC discharges, and the display automagically goes blank, black. I get the +5 from pin 22 of the CPLD pads... forgot to draw that. So, just a little ad on board:
and one less wire to Raspberry Pi GPIO! One less thing to damage... Less instruction in the software loop..
As to the software, I followed the example code from some Arduino project, but of course I use software SPI, and changed everything but the loop structure. but the more you look at that code the more it seems not so optimal.
For example the whole display is only 7 rows of 34 bytes, that are sequentially written to the shift registers. But to 'update' text they first write all zeros, then fill the arrays from the character codes again every scan line, even if no text changes. It seems to me it is much easier to just keep sending those arrays (without clear), and simply modify those _outside the scan loop_ when text changes, that makes scrolling text easier too, less processor cycles, will have to try this, just like a graphics display. there is also an other character set I want to try, but will have to modify that has it has true descenders that do not fit in 7 rows... That is a lot of work. At last the hardware is self protecting now.
All in all, if I replace the 'copy output to input' in the circular text buffer I used in the youtube demo for scrolling text by a getc(), then already I can send it any text that will scroll like a newspaper via ethernet with netcat! So what we have here is an ethernet LED matrix display , probably more than the original manufacturer had in mind, it fits nicely into the LAN here. Will put it in the window and feed your Usenet posts to it, oh, no better not ... :-)