what i've been up to lately

[willib]

well i am working on my data collection device.

i've been trickle charging a battery for a week now , its up to 12.38V and getting stronger every day..

my mini gen is over a friends house , all set up , waiting for some wind..

i have some more ideas on how to make an in house water distiller using waste heat from the stove and possibly from the back the fridge..i still havn't done the window distiller yet , i really should try that..

as it is now i use waste hot water from coffee , which is good for about 2 fl oz of pure H2O

The data collection device is PIC related of course. i have it outputting four Ato D channels , but may use a fifth for calibration purposes

the PIC sends the data to a PC using RS232 .

on the pc side i've got a TTY program i got off the web which takes the data from the PIC and stores it in a file on the pc.

the ten bits of data come in as a high byte and a low byte for each channel one byte per line , that part works perfectly

and i've been  writing code for the data collection program for some time now , with some good results , it may be a week or two before its done though and maybe a month or so before i have it working , and portable (able to move it around)

i found/bought  a Rockwell Drill press at a garage sale on saturday it has a pivot in the bottom front where it connects  to a table and pullys (sp?) at the top rear ,and came with the belts , no motor .. but i'm thinking of using that treadmill motor to power it? just have to attach a pully to it..i still have the drive electronics from the treadmill for speed control.. should be fun ,

[coldspot]

All, good fun I'm sure!

I've been thinking about using a Dehumidifier as a dump load, to gain the pure H2O.

(Just found a place to buy a ceramic 12 V DC 300 Watt Heater for only $29.  , didn't check shipping).

"found/bought  a Rockwell Drill press", GOOD FOR YOU!

I just bought a desk-top mini, very old, montgomery wards brand, working just missing key and handle for running down. Variable speed with knob on front top cover, (looks like a DC motor inside to me but haven't taken apart yet).

 Mine cost me $40. USD, but I'm OK with the deal. Needed many times and have watched this one sit in old pawn shop now quick stop store for a year and the lady wouldn't come down and after another broken bit, .....

[alancorey]

This is for anyone who's been following the PIC saga and might want to try programming a 16F88 themselves.  I just ran across a very tiny and simple programmer (hardware) based on a PIC12F675.  It would be a good second programmer, or a first one if you have someone that can program the 12F675 for you.  It only programs the 16F88 and 87.  I put a picture at http://www.otherpower.com/images/scimages/6871/pp88.jpg  

You use it by connecting it to a serial port and sending the hex file from your assembler or compiler to the port.  It can program and verify the program, but that's it (no debugging, reading back the EEPROM, etc.).  It doesn't require any software on the PC beyond whatever you generate the hex files with.  Looks like maybe $5-10 worth of parts involved (excluding the fancy ZIF socket).  The schematic is contained in comments in the assembler file that you program the programmer from, which I put along with a hex file output from MPLAB at http://www.otherpower.com/images/scimages/6871/pp88_code.zip  This comes from http://home.tiscalinet.ch/str/micro.html but I'm using a whopping 7k to put a copy here in case something happens to that.

It looks as though this might work using a 12F683 instead of a 12F675 in the programmer.  The pinouts are the same, and when I assembled the program with a 12F683 as a target the hex file is identical to the one I got when I assembled for the 12F675.  Some people here have been using the 12F683 and I've got a few around, but I don't have any programs working for the 16F88 yet.  So no, I haven't tried this programmer yet.

  Alan

[willib]

 Alan

i have answered your posts in the past , and got no reply to my questions

yada yada yada bla bla bla ...

anyway

i have been working with the programmer a lot lately ( blueroom's )

it seems to work flawlessly at the moment

have you got the programmer working?

have you got a 16F88?

what others do you have?

I have a pwm program for the F88 if you want it, i'll have to dig it up though

...

[alancorey]

Sorry, I didn't think I'd left anything unanswered.  Just about every weekday I read through all the new posts, then go into the recent activity section and always look for replies in there as well as reading stuff it shows I haven't read before.

Anyway, yes, I've also got the Inchworm (the serial one).  Works fine, at least until I blew a pin in the 16F877A by hooking up the cable to the target board backwards.  I replaced the 16F877A and also got polarized connectors so I don't plug them in backwards again.

I had great hopes for the 12F683 but gave up on it temporarily because there seems to be a complete lack of debugging and emulator support for it.  With my present lack of experience I appreciate being able to step through a program and see what's happening.  I did manage to write my own LED blinker program for one and get that working.  It just turns on a pin, calls a delay routine, turns off the pin, calls the delay, and loops.

I went to the 16F88 because the emulator and debugging support seems much better.  Having built-in serial communications and more memory looks pretty good too.  Just yesterday I read a tip somewhere that programming the chip using the debugger part of the Inchworm/ICD2 has advantages over using the programmer part, at least if you're trying to debug.  I haven't tried that yet.

While I was waiting for the replacement 16F877A I wrote a program for the 16F88 that tries to take an A/D reading once a second and write it into the eeprom until it runs out of space.  It assembles but doesn't run, in fact nothing I've written for the 16F88 runs.  I'm overlooking something or I've got something set up wrong.  Even trying to turn on an LED doesn't work.  I checked with a scope a couple days ago and the oscillator seems to be working (internal 8 MHZ), and I've got a pullup 10K on Vpp.  I need to go over my bank switching again, but I'll find the problem eventually.

So I've got 2 spare 16F877As, about 5 12F683s, 4 16F88s, and a cute 4K IIC eeprom that Dipmicro was selling that I couldn't resist.  I was thinking about the 2nd programmer as being one I could keep stashed in a drawer at work for the slow times, but of course I couldn't do much without the whole project board too.  I spend too much time commuting, where about the only thing I've accomplished is nudging 40 MPG by coasting whenever I can (2002 Ford Escort, ZX2, std., EPA estimate is 33 highway).

 Alan

[willib]

The battery is up to 12.95V with a 0.249 A trickle charge , every day it gets higher highs and higher lows ( when i disconnect it).

it seems to advance quicker after a short discharge cycle

The drill press was only $5 (one persons junk is my treasure)

the chuck is a little rusted as is the table but not seriously , and a little oil should fix it

Alan i am working on your response , sometime tomorrow i hope  

I just finished another part of the data logger , this part takes the four chanels of A to D and splits them into four files of one chanel each, and converts it to an integer,and stores the integers in a file, now it is just a matter of manipulating the data

I had it running at 19200 baud and it worked well , but the file size got too large i think , so i slowed it way down

so now i can track the windmill for a hour and only use 135Kb of the initial file at 300 baud .

i still have yet to hook all aspects of the final system up

wind speed

rotor speed

current and voltage

but it seems to coming along nicely

thats 37 readings per second spread over four chanels is just under 10 readings per second and if it is too slow i could allways change the baud rate

[alancorey]

I knew I had to be doing something dumb and sure enough it had to do with bank selection.  I wasn't doing a banksel TRISA before setting the TRISA bit to turn on my LED.  Fixed that and the LED went on.  Uncommented the calls to my A/D and storage routines, fixed one other minor bug where I wasn't decrementing the EEPROM address between saves quite right, and now when I run it the EEPROM gets filled up with data from conversions.  Slow progress, but I'm not stuck anymore.  I have some interest in making a remote logger that can gather data for a week (hence the external EEPROM) but lack of a real-time clock is a hindrance.  At least with your approach you can use the PC's clock.

So you're doing conversions and stuffing them through the serial port as fast as the baud rate will allow?  Interesting.  Sounds like your max conversion rate is tied to the baud rate.  It didn't quite click in my head before that you're (probably) logging your trickle charge progress with a PIC.  I've thought about doing something like that with my collection of AA nicads.  I haven't thrown one away in 5 years or more, but doing some profiling of charge and discharge rates might reveal which ones aren't up to snuff.

I'm fairly new to successive approximation A/D converters, but the PICs have comparators built in so I suppose they could be used for dual-slope integration (like a multimeter).  Then the number of bits per conversion can go up and the conversion speed down, so there's less noise.

Drill presses, yup, I got one from the dump maybe a year ago with a cooked Taiwanese motor that I haven't found anything close enough to mount to replace it.  I was going to try a heater motor and set it up for 12 volts, but today's dump trip got me a couple of Makita drills.  Maybe I can get a motor and gearing out of one of those to work.

  Alan

[willib]

Alan this is a pwm program for the F88.

http://www.otherpower.com/images/scimages/2965/pwm16FF88

it has no config settings because at the time i was using my own programmer, long story..

i have not tried it with MPLAB so i dont know what errors you may get

i had some help with it , hence all the bank switching comments..

it does not use the internal oscillator so a resonator is required , like on the photo of the boost converter , a few diaries ago.

it uses pin 9 for pwm out

and pin 16 for clkin

and pin 17 for An0 ( analog in )

the config bits can be set in MPLAB to overide the programs lack of config bits.

Or if you copy the program below and set the config bits in MPLAB

:020000040000FA

:10000000850186018301831603138501860183120E

:1000100092010030950083161F30920083120C303D

:100020009700121583160130850001309B00403087

:100030009F00831240309F001F148C0121209500E7

:0E0040001E288C1C21288C101E081F1508007D

:00000001FF

save it as a .hex file

set the config bits in MPLAB,

http://www.otherpower.com/images/scimages/2965/mplab.JPG

go to File -> Import and point to the hex file

that should work also

[alancorey]

Ok, thank you, it assembles just fine both in MPLAB and with Piklab/gpasm.  I get slightly smaller hex files than what you sent for some reason, but oh well.

These PICs are pretty amazing.  I don't know if you've seen this site/product, but here's a PIC simulator written as a Java applet:  http://www.feertech.com/misim/online/index.html  Two of the sample programs for it are video games (Pong and Tetris) where they're using 2 pins from the PIC to generate the video signal.  Makes it seem pretty fast.

  Alan

[rossw]

I just finished another part of the data logger , this part takes the four chanels of A to D and splits them into four files of one chanel each, and converts it to an integer,and stores the integers in a file, now it is just a matter of manipulating the data

As one who has long been doing data collection, parsing and analysis, might I offer a suggestion of practicality?

Rather than storing (n) variables in (n) seperate files, I've found it much more efficient (in many regards) to write one record per sample, with (n) parameters.

Another useful thing is to add a timestamp per record. Again, from convenience, I tend to use unixtime (a single long integer which is seconds since the epoc, but readily converted back to local time, and calculations to find time between events etc is trivial).

Typical records might look like this:

1184020269.  0.0  61  0.0  60   7.8  21.2   8 1027.0 72 33  3  4 0.0
            
1184020329.  0.0  60  0.0  61   7.9  21.2   8 1027.0 71 33  3  4 0.0
            
            

(That's from my weather station, showing timestamp, wind average and direction, gust and direction, temperature outside, inside and a host of other variables. It's easy to grab one record and have all you want, or split just the variable you want if need be)

Just my 2c worth... YMMV

[willib]

BTW , loading PR2 with a higher value

'3F' will get you 8 bits resolution

'FF' will get you 10 bits resolution

 the downside is the PWM frequency will be less.

I havn't tried 208 kHZ ,but 156 kHZ seems to work well with the boost inductor that i have , i kinda miss the 10 bit resloution though

Also i dont know how the 'A' got in the beginning of the program , there is no 16F88A , just the F88..

[willib]

I thought of adding a timestamp, that would require redoing everything though,

the hardest part would be syncronizing the data from the PIC , which comes into the pc as two bytes the high byte followed by the low byte , for each channel, which is in a for loop (on the PIC)from channel 4 to 7..

the TTy program doesnt skip a beat though , even at 19200 baud , because when i leave one channel at 0 volts , every fourth reading is 00..

what language do you use when programming your data collection?

i could use some scheme i suppose to distinguish between channels, because i could tell the pic to output anything before sending each reading..

any ideas

[rossw]

The simple answer is NOT to do timekeeping on the PIC, add the timestamp at the end that is receiving the data.

I have a wide variety of things that I'm monitoring and logging (currently a little over 3,300 items, most every 5 minutes, some every 1, and some every 5 seconds)

My backup weatherstation for example, is a convoluted system. A commercial WX200 system forms the core, but runs at a site without grid power so energy conservation is important. I have an 8-port LANTRONIX terminal server (which draws just a few watts) to connect my weatherstation, security system, home automation system, inverter, lightning tracker and a couple of other things in effect as a "concentrator".

The Lantronix connects to the home LAN, which is connected to my office via private wireless link (I get 6 megabits up and down) for just a few more watts.

In the office are my "real" machines - all running Unix. One of these connects to the LANTRONIX and does all the work there where watts don't count  It collects the data, massages it into whatever form I want (I have written a small C program that connects via TCP/IP and collects the data) which periodically writes the data (and timestamp) to the disk.

Thats all it does.... all it needs to do.

Other processes on other machines subsequently collect the data and do things with it - like showing weather data, or wind information, or security system status or contributing to the australia-wide lightning tracking system etc. But these other processes simply work off the flat files.... which means I can adapt the collection to use whatever I like, and present the information in a consistent and convenient form.

http://weather.albury.net.au/ is one of the live sites. The graphs and images are built either every minute, or every 5 mins, or as required, depending on need.

[willib]

Yeah i was'nt thinking of timestamping with the PIC..

the one tiny detail , which makes this whole timestamping really hard to do is that the TTY program in debug mode converts every char , control or otherwise , to a number , which is nice when all you want is a 0 to 255 'Byte' ..

plus it puts every byte on a new line

otherwise some voltages ( A2D conversions) would come through as control characters like carrige returns and line feeds

its not really that hard to figure out ,i just need to modify the the program that disects the TTY output , or the TTY program itself ,by sticking my routine in

like you said as a byte comes in determine which byte it is add a timestamp and send it to a record or all 8 bytes into one record i mean ( two bytes per channel , four channels)

[alancorey]

I think you've fallen into a trap.  Sending binary data to a TTY program is a quick way to find out something's working but trying to use it much beyond that is bound to be problematic.  I don't know what your end use for the data is, whether you're going to plot it, do some mathematical analysis on it, or what, but converting each TTY capture file into a format you can feed to something sounds tedious.  I think you're going to have to break down and write some programs on the host machine.

I thought you were converting it to ASCII on the PIC before you were sending it, but I guess not.  If you were to convert your values to BCD (binary coded decimal), then add 0x30 to each byte, you'd have ASCII.  Send a value, then a 0x09 (tab), then another value.  Finish the line with 0x0d 0x0a (<CR><LF>) and you've got a nice tab-delimited line.  Still no timestamp yet though.  For short runs you may not need one as long as you know it was x seconds between records.

Ultimately it seems like you'll want to write something on the host though.  That could take your binary data from the serial port, decode it, add a timestamp generated on the host, and save it.  Then you could load it into a spreadsheet or database.  Have you got anything you can write this in?  I'll offer to email a copy of GWBASIC (about 63k) which might do in a pinch (runs under DOS).  GWBASIC is a trap in itself though: the bigger your program gets the slower it gets.  It will let you open the serial port and read from it, also open a file and write to that.  If you're using Windows and you've got Microsoft Office you might be ahead of the game to write in Access or Excel Basic (Visual Basic, sort of).

I'd do it in c under Unix, but that's a steep learning curve for one application if you're not used to it.  One nice thing about Unix is that almost any programming tools you might need are a free download if they aren't already included.  C and Perl come with most, and of course many Unixes themselves are a free download.

  Alan

[willib]

i think my writing skills make things pretty clear ? i donno , i think so.

Lest i say something that i'll later regret, i'll read your reply again later

[willib]

 "I think you're going to have to break down and write some programs on the host machine."

i thought thats what i was talking about.

" If you were to convert your values to BCD (binary coded decimal), then add 0x30 to each byte, you'd have ASCII.  Send a value, then a 0x09 (tab), then another value.  Finish the line with 0x0d 0x0a (<CR><LF>) and you've got a nice tab-delimited line."

you didnt read what i said , the TTY program that i'm using returns the ordinal value of every ' char' that is sent to it.

in other words if the value that is sent to it is Ox0D or Ox0A it does not cause a CR or LF because that is also a valid VALUE of data.

and it politely returns the value hex 10 or hex 13 without causing any interuption in the data flow.

i would really like to use visual basic.net to collect the data but like most very usefull programs its a bitch to learn ,so i am using Turbo pascal which is extreamly fast and fun to use.

[alancorey]

OK, never mind.  I didn't know you were using Turbo Pascal.  It's very capable and you can even do any plotting you need right in it without needing to make your data portable to other applications.  I used it for a few years and the only thing I like better is Borland Delphi, which is also Pascal based but for Windows.  Much easier & better than Visual Basic.

Yes, you're getting ordinal values of individual bytes.  If you have a value like 1017 as a result of an A/D conversion, it probably gets sent as 03 (03 hex) in one byte, then 249 (F9 hex) in the next byte.  You can reconstruct what you started with by doing :

 (3 * 256) + 249 = 1017  (or shift the 3 left 8 bits and add 249)

That's what I meant might be a pain if you had to do it in an external application.  And then of course you still need to scale it to match your vref.  Or you could just label the plot with the right values and leave the data alone since you'll need to scale it to a pixel area anyway.

My new discovery of the day is the 24LC256 eeprom.  32 k bytes for $1.70.  Enough for 8 days of anemometer readings at 1 reading per minute with 2 bytes per reading.

Ok, I'll shut up now.  I'm new to PICs, but I've been programming since 1968.  I used to say my favorite computer games were compilers.  Sometimes I show off too much.  Peace.

  Alan

[willib]

"I used it for a few years and the only thing I like better is Borland Delphi"

I have something to show you then..

its called MikroPascal , pascal for PICs....

it has a vast library of routines built in....

including serial EEProms , LCD displays , RS232 ect , its very cool ..i think you will enjoy it

what i do now is write the code for the PIC in mikropascal and point MPlab at the Hex code , and program the pic with MPLAB..

i have done a lot of assembly with pic uControllers but i find that using pascal is so much easier

http://www.mikroe.com/

oh somewhere on the site there is a free version

"Yes, you're getting ordinal values of individual bytes.  If you have a value like 1017 as a result of an A/D conversion, it probably gets sent as 03 (03 hex) in one byte, then 249 (F9 hex) in the next byte.  You can reconstruct what you started with by doing : (3 * 256) + 249 = 1017  "

Yes that is exactly what comes from the TTy program...

and thats how i put it back together too