new dsl modem

qwest is now refusing to check my dsl line until i replace my venerable cisco 678. the recommended replacement is the gt701-wg. it actually looks like a nice piece of hardware; i'm amazed that qwest made a good decision on something. they couldn't fool me into ordering one from them, though. $100? i found a pile on ebay for $30-40. i'll have to set it up myself, but i wouldn't trust a qwest tech to do it right, anyway. besides, when i called their tech support about it while setting up the ol' 678, i always got the same thing: 'i need to know the settings to put in so it will connect to your hardware on the other end.' 'what operating system are you using?' 'ah, i don't see what that has to do with anything. it's an external modem.' 'well, i need to ask what operating system you're using.' 'linux.' 'we don't support linux. goodbye.' on a tech support call, i can find people reading a flipchart. on the web, i can find people who have done it.

using picprog

i used picprog successfully to read (on both laptop and desktop) and write (on desktop only; wimpy laptop!) hexes to/from pics. i found that sometimes i needed to use --erase with --burn to get it to start when a totally different hex was already on the pic, and --slow helped with the bad idea of trying to burn a pic in a breadboard (picprog --erase --burn -i code.hex --slow). always make sure to read the pic (picprog -o save.hex) before writing in case you screw up the calibrations. sometimes the auto device recognition didn't work, and i had to use --device pic18f877a (for example) the first time i ran it after plugging in the programmer. after the first time, though, it seemed to remember what i had on there. when i first tried to burn a hex to my pics, i found that picprog 1.7-r1 didn't work with my jdm2 programmer (worked for reading, though). i had to upgrade to 1.8.3, which worked just fine. i haven't encountered this yet, but i might need to upgrade to 1.9.0 to use the --reboot option if i use the internal oscillator. jdm programmers have a well-known problem with pics in this configuration because they will start running as soon as they're turned on.

usb oscilloscope

wow, i've gotta try this. it gives you about 60hHz with almost nothing but a pic 18f and a usb port. i think i could do it without the serial bootloader, which makes it even simpler. sure, it's not the most powerful dso, but it's so simple and would help me make a better one if i wanted to. the biggest challenge would probably be software. the author wrote his scope code in visual basic. (!!?! well, i guess i can't complain.) so i'd have to reimplement. but it might be a good way for me to learn how to do usb data xfer in linux, anyway. and maybe i can make an inteface to comedi. i think that would let me use it with xoscope. neither looks like it's released a new version in a while, but i've tried xoscope before (with the soundcard oscope, heh) and it worked okay. i've also been thinking about how to do a cheap and easy high-speed dso. i think video capture adcs are the way to go, with data fed directly to 5-10ns sram. the TVP7001PZP, for example, can do up to 165MHz with a pll internally-multiplied clk for 3 syched channels. built-in scaling and offset, with i2c interface would make it easy to control with a usb pic. for triggers, maybe i could set voltages on dacs and use an opamp comparator with a latch so that the leisurely pic could stop the adc a given time after triggering. the position of the trigger time within the data window wouldn't be exact, but the trigger wouldn't need to be checked at the same speed as the adc. i think it could actually work, and i'm surprised i can't find anyone who's already done it. hmm, maybe that should tell me something.... well, i can't find any reports of failure, either. EDIT: there is an updated firmware version here that provides 5 analog and 8 digital inputs. i tried messing around with gpdasm and gpasm on the hexes, and the non-bootloader hexes produced by gpasm for the 18f458, 18f2550, and 18f4550 are identical. i think i will do the same thing with the superprobe and put a diode instead of a resistor on mclr. rb6 and rb7 will already have some leads for the digital io, so i just need to plug in to the +5 and gnd on the usb to program this thing with my serial programmer.

icd2 clone?

now that i've finished a pic icsp, i wonder how hard it would be to make an icd2 clone for debugging. i've seen a few versions out there, but they all look somewhat complicated. this one is probably the simplest i've seen, but according to the author, it worked with mplab 6.5, didn't work with 7.11, and hasn't been tested with other versions. i guess i'll wait until someone smarter than i (and with more free time) comes out with something that does more in software.

finished my superprobe!

i finally finished my superprobe. i even managed to squeeze it into an empty habanero shake-a-salsa bottle for a stylish homebrew aesthetic. i made just a few changes from the mondo-technology design: 1. i put a diode on /mclr and resistors on rb6 and rb7, so i could program the pic in-circuit without frying everything. 2. i used a 16f877a instead of a 16f870. i changed two lines in supmp.asm: <       list      p=16f870               ; list directive to define processor <       #include          ; processor specific variable definitions --- >       list      p=16f877a >       #include but the two parts are similar enough that when i compile both of these with gpasm, the resulting hexes are identical. oddly, these hexes are significantly different from the SUPER.HEX provided by the mondo-technology page, which i assume was compiled from super.src with an unknown compiler. i used the gpasm version and it seems to work just fine. 3. instead of a passive crystal, i used a ECS-2200AX-200 on osc1 and left osc2 flapping in the breeze. so i didn't need the pair of 22pF caps, but i did find that a tiny bit capacitance (<1nF) from clk to gnd helped the osc get started. 4. instead of using power from the circuit, i decided it was much more convenient and a little safer to use a 9v battery. i have so many of those things from changing smoke alarms (and the superprobe takes so little power) that i have practically a limitless supply. it works great, and it has an amazing number of features for such a simple project. there is one glaring omission, however; there is no ohmmeter. were it not for this, i could almost entirely replace my old multimeter with this superprobe. i wonder if i could add such a feature... microchip shows a circuit and code in an512 for an ohmmeter that uses a capacitor for measuring time constants. the problem is, the resistor to be measured needs to be between the cap and gnd, and the superprobe puts the neg probe electrode at gnd. could i just use a simple voltage divider with the existing resistors on rax? the resistance would then be v/(1-v)*r, where v is the ratio of adc voltage to supply and r is the resistance of the feed resistor. by putting ra1-ra5 and rc6-rc7 high, the feed resistance can be as low as 60 ohm, though this probably isn't much better that just using the 100ohm resistor (puts out up to 85mA, too). on the high end, i could use a 100kohm feed resistor which might let me measure up to 750kohm or so. i guess the big question is whether or not there is room on the pic for this. EDIT: maybe an algorithm like this would work. and i could use the 100, 10k, and 100k ohm resistors. that way i could set the decimal location (in kohms) by the resistor that was used. 10.00 to 99.99 for the 100kohm 1.000 to 9.999 for the 10kohm .0000 to .9999 for the 100ohm and i could get up to 1Mohm by moving the decimal for voltage ratios >.5 with the 100kohm 100.0 to 999.9 for the 100kohm, v > .5 i don't think i would get good precision for much higher than 2Mohm, anyway. the max power dissipation would be with a 0omh load, at .25 watt in the 100ohm resistor and 50mA current, which is no problem. the max power dissipation in the measured device would be for a 100ohm load, at .125 watt and 25mA. this could be a problem for smd parts. typically 1206 and bigger resistors are rated at 1/8 watt, but 0805 and smaller are rated lower. maybe i could get away with it if i just used pulses and delayed between measurements, so that the average power is lower. i read somewhere that smd resistors can have ratings as low as 1/20 watt; if a measurement cycles through the three source resistors with the voltage turned off during the computation, the average power should be less than 1/24 watt. so maybe power dissipation is nothing to worry about. hmm. actually it would probably make the code simpler if i used these ranges: 100.0 to 999.9 for the 100kohm 01.00 to 99.99 for the 10kohm .0000 to .9999 for the 100ohm i would lose a digit of precision for the 1k to 9.99k range. but i wouldn't have to do anything to account for the source resistance.

finished my pic programmer!

i finally finished my high-voltage pic programmer and tested it out. i used ian's icsp jdm2-style design, with a few modifications: 1. i made a one-sided board with 3 jumpers. (ian mentions this variant; i think he designed it to be easy to do one-sided.) 2. i use alligator clips instead of header pins. 3. most significantly, i used a stack of diodes in place of the 8v2 zener. radio smack didn't have an 8v2, and i didn't want to pay s&h for a $.30 part. so i used a 5v1 zener, an led, an ordinary silicon diode, and a 100ohm resistor in series. that puts the programming voltage right in the 12-13v sweet spot, and the led gives me a nice programming activity indicator. i tried it out on a 16f877a and a 18f458 with picprog. my dell laptop couldn't muster the 12v for burning, but it can read them okay. the desktop could also read just fine, but i had problems burning the chips while they were in a breadboard. i could barely limp with a little blink-an-led test program by repeatedly burning without erasing. each time it would write a few more bytes before failing to verify. when i tried it on a 16f877a that i had soldered into a perf board, though, it worked perfectly. first time, every time. lesson learned: breadboards are evil. when i tried out the blink-an-led on the breadboard, i couldn't get a stable clock. that's not too surprising, considering i was using a 20MHz crystal. but i didn't think that nasty capacitance was so bad that couldn't even use the relatively low-speed programmer. oh, well. now that i'm used to soldering, i don't really see an advantage to the breadboard anymore. i think the easiest way to do it is to solder the pic in first, program it, then solder other components and test along the way.

pic bootloaders

the tiny pic bootloader page lists a number of other bootloaders. i haven't looked at all of them in detail, but it sounds like zpl might be the best one for me. it's not much bigger than the tiny bl, and it requires no modification of the bootloaded hex. i think it can even use hexes written to use other bootloaders, but i'd have to try that to be sure. the interface hardware is really simple (3 resistors, one transistor, and an optional led). other than vdd and vss, it only connects to /mclr. so it doesn't use _any_ i/o pins and can be left in while the pic is running. the front end is in python (with pyserial) so it's multiplatform. i just had to change 'import serial' to 'import serial.serialposix as serial' in zpl.py and delete the non-functional serial.py that comes with it so it would use my built-in pyserial. one downside is that the communication is one-way; there is no way to verify the reprogramming. there is an option to rewrite the hex a given number of times, as a quick fix in a noisy situation. given the way it works, it might also be quite a bit slower but i'll have to check that. the bootloader won't overwrite itself, nor will it change the fuses (even though the pic could do either). so fuse configuration changes and changes in clock frequency will need the old jdm2 with the vpp sledgehammer, but at least zpl will never kill itself. for quick dev/debug iterations without big changes to the circuit, this bootloader should be ideal.

3d pdf objects

apparently there a couple of ways to embed 3d objects in pdf files. viewers can pan, rotate, and zoom on a quite smooth 3d model *drool*. i haven't seen much on the really really new format, and it's only supported in new versions of acroread. but the older u3d format is out there and already seems to be near-abandonware. there's a spec def on sourceforge that is the only free implementation i've found so far, though this page has some links i should check out. (click fast, it's tripod!) maybe one of these days i'll write something to convert meshes to u3d so i can embed them in docs.

project management software

in my never-ending quest for project management software that will organize me, i've come across a few that might be worth a try. ganttproject seems to be focused on gantt charts, and can import and export ms project files. gnome planner (formerly from imenio) looks nice and does gantt/resource management, but i've read reviews saying it lacks too many features that ms project has and can't really replace it. opensched sounds very interesting, as it will do the scheduling for you, given tasks and resources. it produces latex reports, too. but it looks like it hasn't been updated since 1999. projman sounds like it has scheduling capability and import/export compatibility with gnome planner, but i can't find out much more about it. xplan looks ancient and crappy. (developed in an all-sun environment? come on, i don't think sun develops in an all-sun environment.) taskjuggler looks like one of the most feature-rich os pm packages out there. i'm particularly intrigued by the mention of 'risk analysis'. i've also had my interest piqued by descriptions of chandler. from their docs, it sounds like a dream come true. but i've also read bad things about their own project management. doesn't bode well when an organization software project seems disorganized.... but i'll give it a look.

EDIT: they finally kicked 1.0 out the door, just before daddy warbucks kicked them out the door. but then the blog abruptly stops in mid 2008. wonder if it will keep going in the foss wild.

free space optics

i just stumbled across RONJA. sounds pretty cool. they claim to get almost a mile with just a high-brightness led.  i wonder if it would work better than my cantenna...