<< Prev Next >>
Been so busy with work and some ad orders that I havenít progressed much. Updated the PC LampMatrix Java class, etc. to add simple setLampOn/setLampOff methods. IT all compiled and worked at the office but last night at home I had problems. Stupid Castor objected to the movement of the matrix classes from the devices to control package (where they properly belong). So to make Castor happy, I moved them back to devices.
Still need to do a bit more stress testing and streamlining of the BS2 code so that I can do several lamp commands per second.
The big thing of the last few days was the arrival of my Tektronix T922 oscilloscope in the mail last week. Iíve printed off the manual and downloaded and read lots on the web.
Got the scope working to look at the power supply output for my various breadboards.
The scope is a bit flaky on some settings and I donít think is perfect, but is good enough for me to see the ripple.
First hooked it up to the PS I built from the kit (the one all the Picaxe folks suspected as being the problem with my Picaxes). There is a ripple of about +0.2V with a frequency of about 8khz. So 8000 times per second there is a 0.2V spike from 4.9V to 5.1V.
Last night measured the PS circuit on the Picaxe breadboard. It was a lot more interesting and noisy. Looks like a series of ripples together, with a frequency of 40khz, and a peak-to-peak voltage variation of around 0.2V also. It varies up and down from the 4.9V so that would cause fluctuations approximately in the 4.8V to 5.0V range. I keep wondering if that 40khz ripple has anything to do with X10 120khz.
I might retest that when plugged into an isolation transformer, or with all X10 devices unplugged in the house.
Going on holidays soon so there will be 10 days with no activity. That part is depressing.
Did some more testing with the oscilloscope last night. I tried plugging the wall wart into the Picaxe power supply into the isolation transformer. I wanted to see if that cleaned up the ripple or not.
The signal was smoother, with the saw-toothed spikes only about 30mv in height, spaced about .15ms apart (roughly 7khz). There was also a larger transient blip that flew by on the screen every second or so, probably about 60mv in height.
The scope read 0V for this, not 5V though, when in DC mode. I think the isolated ground causes that.
I then went back to the normal set up (no iso xformer), and re-measured. The trace I got was different from the night before. Maximum peak-to-peak difference was about .18v, with 2 distinct pulses. Only one would fit on the screen at a time with my settings (int/auto .1v 5usec). The distance from one type of pulse to the next was about 45us, or 22khz frequency.
I tried then measuring as I unplugged X10 controllers and devices, but this didnít seem to make any difference. Perhaps the laptop itself was causing the ripple. I should have powered it off.
So, it looks like the iso xformer was successful in reducing noise, from .18v to 30mv, which is good. The frequency of the pulses was also reduced.
Also wrote some Java test code to see how quickly I could turn the lights on/off.
The test sequence was to set all 4 lamps on in order then off again. I also altered the BS2 code so that LED flashing was reduced to one blip of 40ms duration (instead of n blips of 100ms duration).
With no pauses in the Java code, it would do about 7 full iterations before the PC received a serial port break interrupt and framing error. After that, nothing worked.
Even resetting the Picaxe at that point did not help. Maybe the BS2 was in a funny state, but it seemed to be responsive. I actually had to power cycle the Picaxe and BS2 in order to get the commands working again.
If I inserted a 10ms pause between the lamp-set commands in Java, all worked 100%.
So it looks like over time the BS2 was just a bit slow to respond, probably drifting in the cycle and finally getting out of alignment enough for an error to occur.
Perhaps removing or further reducing the LED blips would help.
It would be nice to get this working as quickly as possible, as it would then be possible to have a nicely response attract mode lighting display controlled from Java.
At the end of the day, I should probably just be hanging the LEDs off of the PC serial i/o and Picaxe i/o lines so that there is no explicit time wasted to indicate work going on.
Was on holidays from Jul 10-19 so absolutely no progress. BS2p24 chips arrived on the 19th. Got overcharged for GST because Parallax screwed up.
Last night did more testing. Just trying to send lamp commands from the PC as quickly as possible, hopefully without any sleeps or pauses in between.
I modified the BS2 code so that we no longer have the sequential LED flashing to indicate sends/receives. That was taking quite a bit of time (20ms or more). I removed the LED from output P5 but kept the one for P4. The one for P4 is now just a general status LED. Flashes on reset and on timeouts.
I took LEDs and put it them in parallel with the RX and TX lines so they would be flickering when there is serial I/O activity. Not transmitting any responses now so I didnít see the TX LED work. The RX LED, right at the MAX232 output, was on all the time but flickered when data sent. Took it off for now.
Also added a debug flag and a response-required flag in the code. No longer echoing back the commands in a response. I will need to add proper response code for some items, and should add response code for errors.
Tested with no sleep time between commands and it still failed as before, but I was able to send over 100 commands before the break interrupt was received (only was able to send about 30 before). Sleep time of 5ms seemed to work good repeatedly with tests of 50 loops or 400 commands.
With 3ms sleep time, it failed quickly.
Then did a stress test with 5000 loops or 40000 commands. The 5ms test did fail at some point. Then I went back to 10ms and re-ran the test. This worked fine Ė all 40000 commands sent and lights flashing with no problems.
Note that sometimes following a failure with the break interrupt that I had to power cycle the BS2 and sometimes the Picaxe also.
So it looks like for now we need to have a pause on the PC side to ensure robust communications.
Next test will be to try just having one pause every n command say (currently n = 1 and pause time is 10ms). Perhaps try n = 25.
Now that I have the BS2p24 chips, I would love to swap one in for the BS2. But Iím wary of pulling the chips off the board and possibly bending the pins. Also, if I blow something up, better the BS2 than the BS2p24. But I would like to see the BS2p24 work. Decisions decisions Ö
Also looked at one of the logs in which a break interrupt was received (older code, when the LEDs were still being flashed). It looks like all was well, and the send code consistently waited 100ms or more for CTS to be raised indicating that the BS2 was ready to receive (sitting on a serin).
However, all went awry when the CTS wait time was suddenly 0ms. This tells me that we sent a command while the BS2 was still busy sending a response or something. I donít know why CTS would be high, but very shortly after that the BS2 stopped responding.
I was just thinking that following a send cmd, the PC code should spin until CTS goes low. That may guarantee that the next send will only occur when the BS2 is ready. Hard to say. Another thing to monkey around with I guess.
I also can probably reduce my CTS sleep wait times from 10ms to a smaller value in order to be more responsive.
I think in general my guess is that if the UART contains 2 or more commands at once, then comm can be screwed up. I could possibly enqueue on the output buffer empty event.
Nothing done on the 21st. Last night just did more testing with timings, etc. Didnít really get anywhere, although I made minor changes to the BS2 code. Because timing is so tight at 2400 baud, I am unable to read the length byte, validate it then read the rest. I have to read the length and then the number of bytes specified in the length byte, all within one serin instruction.
Therefore if things are out of synch, an overly large length byte value can be read and things go awry. This would overflow the buffer for the serial data and overlay valid RAM. So I at least moved the array so it is the last declared in RAM storage. Hopefully if any overflows occur, this will not wipe out other used RAM bytes. I think this might explain why the BS2 had to be power cycled sometimes when problems occurred.
I also at least added the length check after the serin. The damage is done, but it will be detected and a response can be generated (havenít done that yet).
Also tried for the first time to run the app from the command line instead of from within NetBeans. I thought Iíd better do that now in case any new timing issues came up.
It seems to still work and run a bit faster as expected so thatís good.
Spent almost an hour however trying to get the damned comm API to work. Was receiving a NoSuchPortException on start up. Tried stuffing the comm.jar in all possible spots.
Finally dumped out the "java.home" system property. In NetBeans, this pointed to the JSDK location on the D: drive. But from the command line, pointed to the JRE installation on the C: drive. It looks like the code expected the comm.jar in %JAVA_HOME%/lib, not in %JAVA_HOME%/jre/lib.
Once I copied comm.jar (and the properties file) to the lib in the JRE install on C:, all worked. You would expect that it would pick up the jar in jre/lib/ext but it didnít.
Also changed the MsgLogger class to synchronize all methods that actually do I/O to the PrintWriter object. Hoping this helps messages to be written in the correct order. Also added milliseconds to the msg timestamps, as many things occur sub-second. Resolution seems to be 10ms of course.
My system seems to be able to handle about 20 lamp commands per second, or about 50ms total per message. Not sure why itís that slow. We transmit 5 bytes at 2400 baud which should take a little over 20ms. To send the 2 byte command to the Picaxe should take about 10ms. The BS2 should then go to the serin command. So I would expect a turnaround time of 30-35ms rather than 50ms. Hmmm. Not sure if I checked my final test for times or not.
I noticed from the command line, the mean value for CTS wait time was about 23ms. From NetBeans it was 20ms. I attribute the longer wait to the fact that the PC code runs faster from the command line.
I guess if I factor in the time taken to execute the PBASIC commands themselves, that would explain a few ms (BS2 average instruction time is 250usec, but serin/serout are longer of course).
I decreased the sleep time waiting for CTS to 1ms from 10. This could have lead to a good speed up, but it looks like it really needed to wait 20ms most times anyway. Sometimes 15-18ms. So not much gained but ever ms helps.
I have all the components to build the breadboard with the BS2p24 now except the Sipex 232ACP chip for RS232. I am hoping it will do 4800 baud reliably, with the luxury of doing the length check.
(Afternoon). Bought some 232ACP chips and a couple of other items. All ready to go now.
Looked at a relay controller board someone was selling and it made me think that I could probably build one pretty cheaply and easily using TIP102 transistors as the "switch", along with a cheap Picaxe for the controller.
Use a Picaxe with 8 outputs, with a ULN2803 chip attached to 8 TIP102s. In reality I may only need 6 relays for Solar Ride. Turn the Picaxe outputs on and switch the load to ground.
Program logic would be trivial. Same serial setup as for the lamp controller. Logic is:
- Wait for serial command to fire coil x for n ms.
- When command received, immediately disable interrupts.
- High x.
- Pause n.
- Low x
- Re-enable interrupts and go wait for next command.
No problems worrying about the coil locking on in general. The control anything controller doesnít do any better. If you give it a time parameter it operates about the same way.
The only problem with this solution is that the high currents switched through the transistor exceed the limits of a breadboard (2 amps). I guess we could buy a board already drilled and plated and use that for this portion.
Total cost without the board is under $15 Ė pretty attractive.
Spent several hours Sat. with the BS2p24. Pretty much a complete success. Put the chip on a new breadboard with a 7805 regulator circuit, download connector, run-time serial connector and Sipex 232ACP chip for RS232.
Worked well and no mistakes. Measured the regulated voltage at 5.00. Perfect! Hooked up the scope to check for voltage spikes. None! Absolutely flat signal. I added a .1uf cap at the power supply and put it on the other side of the LED (as compared to the other breadboard). That may have helped. Too stupid to remove the .1 cap and see what difference it made.
Also added a pushbutton for resetting the BS2p without having to power cycle the board. And I added a .1uf cap across the power pins of the BS2p, right beside the chip. The power pins are adjacent so this is easy. The Picaxe power pins are on opposite sides, making this addition awkward.
Next had to modify the PBASIC code to add the conditional compilation constants for the speed differences. Baud rates, PULSOUT times and SERIN/SEROUT times also are machine dependent.
Replaced the BS2 board with the new BS2p board and it worked perfectly first time. Then I bumped up the baud rate to 4800 from 2400 and that worked well. Did some timing and stress tests, and also played with the sleep wait time between commands.
Most initial testing done with a 10ms sleep time between PC commands. All tests done with NetBeans.
Here are the timings and observations:
- BS2 vs BS2p Ė the CTS wait time before commands dropped instantly from about 20ms to about 8ms. So that tells me the processing time on the BS2p was a lot faster as expected.
- At 2400 baud, the time to execute 500 loops on BS2 was 3m26s. On the BS2p measured 3m00s. That works about to about 6.5ms per command faster.
- At 4800 baud the time for 500 loops on BS2p dropped immediately to 2m23s. So the baud change increased overall throughput by 20% or so. Observed occasional long waits as the PC did disk I/O. This would be all of the debug messages generated for the log file.
- Tried removing the sleep time between commands on the PC. Unfortunately, still received a break interrupt, but only after about 1250 commands (with BS2 the break would occur after about 110). CTS wait time was usually 0ms.
- Tried a 5ms sleep time. This worked. 500 loops done in 2m31s. Average CTS wait time was about 11ms (higher than when the sleep time was 10ms Ė how to explain?).
- Next turned off debug reporting in the log, in an attempt to eliminate the occasional long pause. With a 5ms sleep time between commands and 500 loops, time dropped to 2m00s. About 30 seconds faster than before.
- 10ms sleep time: 2m09s.
- 3ms sleep time: 2m09s.
- 1ms sleep time: 1m56s.
- 1ms sleep time with 5000 loops. Died after about 16 minutes, which I estimate to be about 32000 commands in. With debugging off I couldnít see the exact error. Made changes to some messages that should have been error-type instead of debug.
- Re-ran test 1ms and 5000 loops. This time it went to the end and took 22m11s (2m13s interpolating to 500 loops). A bit slower than before. Works out to 30 commands per second.
So it looks like we still need that sleep time between commands on the PC, although 1ms versus 10ms doesnít seem to make that big of a difference. I would probably use 5ms.
Logging with debug messages is expensive. Perhaps I could create an in-memory message queue, and write them to disk instead of pausing between commands.
One observation about the occasional pauses: they seemed to last 3 seconds or so, and the BS2 serin timeout is 3 seconds. It may be that something is wrong and the PC doesnít see the CTS high? I should check this out further. I think I noticed that the pause would end as the BS2 serin command timed out (evidenced by LED flash).
Anyway it all looks pretty solid at 4800 baud. I still need to test with the BS2 reading and validating the length byte. If that works we get more reliability.
Also need to test with setting the entire matrix. This is a longer command. For attract mode this might be better to use when altering many lights at once Ė e.g. for alternating flickers, etc.
Yesterday started poking in the Solar Ride game looking at doing the physical lamp matrix hook up. I think I can do the hook up without making too many changes. I need a "diode board" that the Picaxe will connect to. Then connectors from the diode board to the actual lamp wires. I will need to cut off the existing Gtb connectors. I hate to do this but it is the only way for now.
On the p/f itself, I think I just need to break the command return line into 4 segments Ė one per matrix column return. That is a minor change I believe.
I think I will next identify each lamp wire, and determine my rows and columns. Then I can begin the hack. Need to do a lot of connector crimping, wire tinning, etc. Then need to jam all the wires and TIP transistors in the Picaxe board for the full matrix.
I will be very happy when this is all done and working!
Just spent some time under the hood last night mapping out the physical wiring for the lamps. Doesnít look too bad. The Solar Ride wiring page for the lamps seems 100% accurate. All 25 lamps are on two dedicated connectors, A3J3 and A3J5.
Was interested mostly in how the common return lines were wired. Mapped that out on paper. Need to split these up into the 4 columns. Spent today at lunch getting the row/column assignments. My wiring hacks mostly involve just breaking up the common line which is attached to 18 lamps into 7+7+4 (thinking now I might as well make it 6+6+6), then joining the other 7 together (4 at the top are already joined). Have to trace a couple of the cloth covered wires to see if I can use them or how I have to leave them hooked up.
Next problem is the connector issue. The A3J3 and A3J5 connectors are (I believe) Molex .156" connectors. I think they call this type "card edged". They are flat. Given that they wonít mate to anything I have currently (and are probably all corroded), I think I will indeed cut them off. I did spring terminal out to look at the pin.
Searched the Molex site today. The .156-spaced Trifurcon connector pins (for .093" round connectors - 08-52-0113) are designed for 18-20 gauge wire. The .100 KK terminal pins I use on the breadboard (08-50-0114) are designed for 22-30 gauge. No overlap.
Checked the .062" round connector info also. I think the tin pin number is 02-06-1101. These are designed for 18-24 gauge wires. So I think since I bought the .062 kit I can use this, as there is a good overlap in wire size. Thus I can mate the 20 gauge wires in the A3J* connectors to the 22 gauge wire I need to use on the breadboard.
So I will cut off the A3J* connectors and housing, and wire that up into .062 connectors. Then I will take my 22 gauge wire and fit the .062 connectors on one end, and the .100 connectors on the other end for the breadboard.
The breadboard will be called the "lamp connector board" and will just contain connectors and 25 diodes for the lamps. It will be the adapter between the Picaxe and the physical lamps.
The soldered lamp connector board. Adapter between Gottlieb connectors and breadboard connectors,
plus diodes needed to make the matrix work.
The more or less final lamp matrix board. Due to odd Picaxe power problems, I needed the
various on/off switches to get it to power up properly.
Started hacking up the Solar Ride playfield wiring last night. Looks like my hacks can be minimal. I traced the rest of the ground line to the lamps, so I know the physical wiring to all 25 now.
It looks like all go through the switch on the tilt relay, except the "Same Player Shoots Again" (SPSA) light, which will stay lit even during tilt (so as not to scare the player I guess).
Last night I just made 2 snips on the ground line and soldered three 22 gauge wires, about 6 feet long each, to the new matrix columns. I need to next unsolder the wires going to both leafs of the switch on the tilt relay. The black and slate wire to 6 lamps, plus the special wire to the SPSA light will be combined, then a 6 ft wire run from there.
I also unsoldered the black and slate wire from the 20K light.
If a tilt occurs, we will turn off the lamps via software. We can also use tilt warnings instead of a hardwired tilt.
So in summary there are 18 lamps with grounds connected by the bare wire stapled to the playfield. A black and slate wire was connected to the 20K light to link those 18 to the rest. The black and slate wires run from the tilt switch to the top lane 1, then to the upper left kickout hole, then to the 20K light. Also from the tilt switch it goes right to the Extra Ball light.
The other side of the tilt switch has a wire that runs to the SPSA light.
I played with connectors and changed my mind regarding A3J* connection. I can simply take some of the .156 header pin blocks I bought and solder my wires directly to the base of these, then plug this into the existing connectors. Not a robust solution but the advantage is that I donít need to hack up the existing connectors, and Iím just doing simple soldering of 25 pins, which will be faster than crimping 50 pins!
My other alternative to still think about today is getting a proto-board and drilling some .156" spaced-holes for a more proper connection.
R.I.P. Dad. Finshed my light re-wiring on the Solar Ride playfield last night. Didn't have to make many changes. Swapped all bulbs for new #47s and tested them all. A couple of flaky sockets but all are working now.
Summary of p/f wiring hacks:
- Unsoldered black and slate wires from 20K light. Left the 2 wires soldered to each other.
- Cut 2 bare ground wires to break the lamps into 3 groups of 6.
- Unsoldered the wires from the second T (tilt) relay switch. One terminal had two black and slate wires. The other had 2 other wires. One of those wires went to A6J4-6. The other went to SPSA light.
- Tied those 2 black and slate wires plus the wire to SPSA together and also to the new 22g column return wire. Used a marrette cap. The wire to A6J4-6 is left unconnected.
- Ran new 22g wires from the other 3 6-lamp segments. These are the column return wires.
I also bought some cheap protoboards at that Semitron place near Active. One has holes space .156 apart so I could put my .156 connectors on there. But the holes are too small. Molex site says the pins have diameter of .045 inches. Decided I needed a 3/64ths drill bit (.0469 inches). Of course standard sets only go to 1/16th. Went to Home Depot and checked the Dremel stuff. Was about to give up when I see this micro-drill set of 7 bits for $14.98 that includes 3/64ths!
I also bought another protoboard that has no holes drilled for the first half inch or so around the edges. I might try drilling my own holes and mounting the header connector there. These protoboards were under $3 each so if I wreck them it's not a big loss.
These boards have copper connectors on one side and .1 hole spacing. So they will be good for everything except the .156 connectors.
So next step is try and get my .156 connectors attached to a protoboard so we can just plug in the existing Solar Ride connectors to it. Then add the .1 connectors and diodes.
<< Prev Next >>
Last updated: September 26, 2008