Post by thread:%&

Jerry Iacobucci wrote: > > I like to thank you in advance for any information. > > I am trying to use a RF Transmitter and a Receiver for data communications. > I was told I should encode data to PWM then Xmitt via RF then decode the > PWM on the receiver side. Does any one have any experience with PWM > encoding and decoding. I could use either a software based PWM or hardware > based Pics. You should try to do two things righ from the start : 1) Ensure that your PIC RX code can adjust itself to slight variations in bit length. Depending on your TX side, you may find the bit lengths to vary slightly. 2) Try to make your codes DC-less so your rf discrimination is better. Manchester encoding is great for this, and quite do-able on a PIC. > I have been doing tests with out any encoding, and I keep getting stray > data from RF. Welcome to RF! If you find a way to solve that problem, you'd become very, very rich! -- Friendly Regards /"\ \ / Tjaart van der Walt X ASCII RIBBON CAMPAIGN .....tjaartKILLspam@spam@wasp.co.za / \ AGAINST HTML MAIL |--------------------------------------------------| | WASP International | |R&D Engineer : GSM peripheral services development| |--------------------------------------------------| | Mobile : tjaartKILLspamsms.wasp.co.za (160 text chars) | | http://www.wasp.co.za/~tjaart/index.html | |Voice: +27-(0)11-622-8686 Fax: +27-(0)11-622-8973| | WGS-84 : 26¡10.52'S 28¡06.19'E | |--------------------------------------------------|

> I am trying to use a RF Transmitter and a Receiver for data communications. > I was told I should encode data to PWM then Xmitt via RF then decode the > PWM on the receiver side. Does any one have any experience with PWM > encoding and decoding. I could use either a software based PWM or hardware > based Pics. There are a whole bunch of ways to transmit PWM, including gating the RF carrier on and off according to a timer output.. That, and the methods to receive it are a huge subject. > I have been doing tests with out any encoding, and I keep getting stray > data from RF. You will. That's the nature of an RF link. Error correction codes fix some errors, and error checking mechanisms let you know when an error occurred, but don't fix it. Error-free RF links do not exist.

At 12:52 AM 22/04/99 -0400, you wrote: Hi Jerry, We were talking about the Indigo radios and on these there is no need for the PWm. Also stray Rf is eliminated as it is all handled by the onboard PIC. If this is not the radio you intend using please excuse the post. Peter {Quote hidden}> I like to thank you in advance for any information. > >I am trying to use a RF Transmitter and a Receiver for data communications. > I was told I should encode data to PWM then Xmitt via RF then decode the >PWM on the receiver side. Does any one have any experience with PWM >encoding and decoding. I could use either a software based PWM or hardware >based Pics. > >I have been doing tests with out any encoding, and I keep getting stray >data from RF. > >Thanks again for any help on this. > > >Jerry Iacobucci >.....jerryKILLspam.....canlinks.com > Peter Grey Noesystems

Hello all, I've got a problem. I'm creating program for a couple (100+) of devices. Those devices will be working in a cluster. A PC will be used to communicate with them. But ... I have to adress all those devices one-by-one. That means they will need unique adresses. That's not really a problem, cause I can : Set an ID-value, assemble the program, burn a controller, change the ID-value, assemble the program, burn the next controller, and-so-on. If that's how it must be done, that's the way I'll do it. But when there is another way (like using an Auto-increment counter), I sure would like to know :-) So, if someone knows how to make my life easier, please let me know. Greetz, Rudy Wieser

Caisson wrote: > <snipped> > If that's how it must be done, that's the way I'll do it. But when there > is another way (like using an Auto-increment counter), I sure would like to > know :-) > > So, if someone knows how to make my life easier, please let me know. > > Greetz, > Rudy Wieser Alternate methods that come to me just now: Each PIC could have a 24C01 attached, drop the ID value in the C01 & read it in on startup. A PISO shift register set could load a bunch of jumpers/dip switches/broken PCB traces, at startup time. A Dallas I-Button could load the I-Button's serial number in at startup. (I still wish PICs had a serial number, some times.) Cheapest is probably the most labor intensive, which you've mentioned. Mark

(Note: I haven't been receiving my own posts from the piclist, though I assume they're getting through, since I've had a reply from two or three... Is this problem typical to the list and being resolved, or is it just me?) Anyway... Once you assemble the program, identify the bytes in the hex file which change when you change the ID. Then set up a small program (could be basic, C, whatever. You might even use grep to search and replace it) and put it in a batch file which automates the entire thing for you. start Modify file Prompt for new chip program chip Goto start I hope this helps, and good luck! -Adam Caisson wrote: {Quote hidden}> > Hello all, > > I've got a problem. I'm creating program for a couple (100+) of devices. > Those devices will be working in a cluster. A PC will be used to > communicate with them. But ... I have to adress all those devices > one-by-one. That means they will need unique adresses. > > That's not really a problem, cause I can : Set an ID-value, assemble the > program, burn a controller, change the ID-value, assemble the program, burn > the next controller, and-so-on. > > If that's how it must be done, that's the way I'll do it. But when there > is another way (like using an Auto-increment counter), I sure would like to > know :-) > > So, if someone knows how to make my life easier, please let me know. > > Greetz, > Rudy Wieser

> Caisson wrote: > > <snipped> > > If that's how it must be done, that's the way I'll do it. But when there > > is another way (like using an Auto-increment counter), I sure would like to > > know :-) > > > > So, if someone knows how to make my life easier, please let me know. > > I don't know about PicStart Plus but you can generate the serial number with ProPic 2 programmer, you can specify the start address, the size and the increment of the serial number. /"\ Friendly Regards \ / X ASCII RIBBON CAMPAIGN Octavio Nogueira / \ AGAINST HTML MAIL =================================================== nogueiraspam_OUTpropic2.com ICQ# 19841898 >From the creator of ProPic, ProPic 2 now much better New ProPic 2 homepage: http://www.propic2.com PIC Programmer for Windows with down to earth price ===================================================

On Thursday, July 01, 1999 8:48 AM, Adam Davis [SMTP:@spam@adavisKILLspamBALADYNE.COM] wrote: > (Note: I haven't been receiving my own posts from the piclist, though I assume > they're getting through, since I've had a reply from two or three... Is this > problem typical to the list and being resolved, or is it just me?) Although there was talk of changing this, I think the PICLIST defaults to not copying you with your own message. There is a way to change it ... I think the instructions are included in the original sign-on message you should have received. Tjaart has a PICLIST FAQ I think .. unfortuantely I can't find the link .. Tjaart ? Eric

> Van: Adam Davis <KILLspamadavisKILLspamBALADYNE.COM> > Aan: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Onderwerp: Re: Generating sequential serial-numbers using MPLAB & Picstart+-An Auto-increment counter ? > Datum: donderdag 1 juli 1999 15:47 Hello Adam, > (Note: I haven't been receiving my own posts from the piclist, though I assume > they're getting through, since I've had a reply from two or three... Is this > problem typical to the list and being resolved, or is it just me?) This is no problem, it's just the (old) default. You can ask the server to send you a copy of your own messages (as will be de new default). How ? I'm not sure anymore, but you can ask the server to send you a list of commands. The way to do it is described in your "Hello, nice you joined" message. > Anyway... > > Once you assemble the program, identify the bytes in the hex file which change > when you change the ID. Then set up a small program (could be basic, C, > whatever. You might even use grep to search and replace it) and put it in a > batch file which automates the entire thing for you. Right, that's what I thought of too. But because of the fact that the PICSTART+ only works with MPLAB, I would be forced to : Program a chip, call the routine that modifies my HEX-file, reload the project (making sure the last version of the HEX-file will be used when programming the next chip), and start programming again. It's allmost the same bore as manually changing the Source-file, assemble it, and program a chip ... :-( Ah well, To bad that there is no counter available for this purpose. Greetz, Rudy Wieser

<x-flowed>This may not be that easy not only will the byte change, the checksum calculated from this byte changes as well! It will require some knowledge about the hexfile and some programming Peter spamBeGonepvhspamBeGonevertonet.com {Quote hidden}>From: Adam Davis <TakeThisOuTadavisEraseMEspam_OUTBALADYNE.COM> >Reply-To: pic microcontroller discussion list <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU> >To: PICLISTEraseME.....MITVMA.MIT.EDU >Subject: Re: Generating sequential serial-numbers using MPLAB & Picstart+ > -An Auto-increment counter ? >Date: Thu, 1 Jul 1999 09:47:31 -0400 > >(Note: I haven't been receiving my own posts from the piclist, though I >assume >they're getting through, since I've had a reply from two or three... Is >this >problem typical to the list and being resolved, or is it just me?) > >Anyway... > >Once you assemble the program, identify the bytes in the hex file which >change >when you change the ID. Then set up a small program (could be basic, C, >whatever. You might even use grep to search and replace it) and put it in >a >batch file which automates the entire thing for you. > >start >Modify file >Prompt for new chip >program chip >Goto start > >I hope this helps, and good luck! > >-Adam > >Caisson wrote: > > > > Hello all, > > > > I've got a problem. I'm creating program for a couple (100+) of >devices. > > Those devices will be working in a cluster. A PC will be used to > > communicate with them. But ... I have to adress all those devices > > one-by-one. That means they will need unique adresses. > > > > That's not really a problem, cause I can : Set an ID-value, assemble >the > > program, burn a controller, change the ID-value, assemble the program, >burn > > the next controller, and-so-on. > > > > If that's how it must be done, that's the way I'll do it. But when >there > > is another way (like using an Auto-increment counter), I sure would like >to > > know :-) > > > > So, if someone knows how to make my life easier, please let me know. > > > > Greetz, > > Rudy Wieser _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com </x-flowed>

Yes, this list defaults to not sending you your own messages. I should have checked with the list server before sending that message. For those needing to change this, send the following in the body of a message: set piclist rep to: EraseMELISTSERVMITVMA.MIT.EDU It will send you confirmation email, to which you reply 'ok' as you did when you signed up for the list. Thanks to everyone who helped! -Adam Eric Oliver wrote: {Quote hidden}> > On Thursday, July 01, 1999 8:48 AM, Adam Davis [SMTP:RemoveMEadavisEraseMEEraseMEBALADYNE.COM] > wrote: > > (Note: I haven't been receiving my own posts from the piclist, though I > assume > > they're getting through, since I've had a reply from two or three... Is > this > > problem typical to the list and being resolved, or is it just me?) > > Although there was talk of changing this, I think the PICLIST defaults to > not copying you with your own message. There is a way to change it ... I > think the instructions are included in the original sign-on message you > should have received. Tjaart has a PICLIST FAQ I think .. unfortuantely I > can't find the link .. Tjaart ? > > Eric

In SX Microcontrollers, SX/B Compiler and SX-Key Tool, OzStamp wrote:Hi All. Will be doing a little project that requires monitoring a battery. Reading thru the SXB online doc that we just printed out .. It occurs to me that it would be easy to accomplish that using the schematic on page 37.. With monitoring a battery we mean charge it when needed.. So if the voltage across the battery terminals falls below a certain value start charging and when the voltage reaches the max voltage allowed across the battery .. stop charging..or maybe even trickle charge... Some of the commercially available chips from MAXIM ( 712/713) and many other from vendors like LTC SGS etc are not readily available and now with the low cost of the SX chips .. that sounds like a good application for them. Has anybody already been down this path and willing to share their findings. I will be exploring this issue in depth so will share what we find as time goes on.

Cheers Ronald Nollet Australia ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=204932 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)

In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:If the charging current is pulsing you will need to filter the voltage from the battery. Or else you will get screwy readings. Other than that, it should work. You might want to also monitor the battery temperature so you can stop charging if the battery gets too hot. Bean.

---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=204932#m205140 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)

In SX Microcontrollers, SX/B Compiler and SX-Key Tool, OzStamp wrote:Hi Terry. Prototyped the circuit and used various methods monotoring the voltage. Using the analogin method we get very noisy readings.. Stuffed around with lots of dif caps and settings.. aborted that... Tried the PWM ADC principle .. works good .. well enough for the application. Stumbled across another method .. really very simple. As we have done this many years ago but we did not use a micro just some voltage comparators to sense various levels and windows to trigger the charging .. etc etc ... all simple stuff.. The micro will do other stuff as well.. not just monitor the battery... Now here is a trick Using the compare command. Setup the circuit as per page 47 in the onLine help manual. Use 3 line program..and also add 1 additianal resistor from RB.O to the centre point (V Threshold on RB.2) of the 2 resistors. Effectively creating some hysteresis..also use RB.0 to signal the circuit for charging.. Some more components needed.. but for simplicity did not add all that stuff.. Thinking about adding the temp monitoring as well... thanks Terry. So now the RB.O comes on at 1.9 V and goes off at 3.0V. Awesome exactly what we need... no caps no tuning .. fricking simple..

5v + --------[10K]-----|-----[10K]-------- -(0V) | RB.2---------------| | RB.0-----[3.3k]----| RB.1---------------------<< Measure volts here Cheers Ronald Nollet Australia ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=204932#m205146 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)

James Ollingers's collections: Exposure meters & some tech stuff http://www.jollinger.com/photo/meters/index.html Cameras & related http://www.jollinger.com/photo/cam-coll/index.html _______________________ Adox Sport Agfa Billy Agfa Optima Amica Eyelux Ansco Anscoflex II Ansco Readyflash 4x5 Ansco View Argus Argoflex EM Argus C3 Braun Super Paxette Busch Pressman Model C Canon A-1 Canon AE-1 Canon AE-1 Program Canon AL-1 Canon AT-1 Canon Canonet Canon Canonet QL Canon New Canonet Canon Canonet G-III Canon Demi S Canon EF Canon Elph LT260 Canon EOS-1 and EOS-1N Canon EOS 40D Canon EOS 650 Canon EOS 850 Canon EOS Elan 2e Canon EOS Rebel 2000 Canon EXee Canon F-1 Canon FT and FTb Canon FX Canon New Sure Shot Canon Pellix Canon Photura Canon Powershot A85 Canon Powershot G2 Canon Powershot S100 Digital Elph Canon Powershot S500 Digital Elph Canon RM Canon Sure Shot AF35M Canon Sure Shot Supreme Canon Sure Shot Z85 Canon Sure Shot Z135 Canon T50 Canon T70 Canon T90 Ciro 35 Coronet 3-D Counterfeit "Canon" Q5200 DeJur D-3 Delta Stereo Fed 2 Graflex Century Graphic Graflex Graphic 35 Graflex Junior Graflex R.B. Series B Graflex Speed Graphic Haneel Tri-Vision Iloca Realist 35 Kodak 1A Autographics Kodak 2A Brownie Model B Kodak 2C Brownie Model B Kodak Brownie Bulls-Eye Kodak Brownie Hawkeye Kodak Brownie Holiday Flash Kodak Brownie Reflex (Synchro) Kodak Brownie Junior 620 Kodak Brownie Target 616, 620 Kodak DCS 215 Kodak Disc 4000 Kodak Disc 4100 Kodak Disc 6000 Kodak Disc 8000 Kodak Duaflexes Kodak EasyShare C310 Kodak Instamatic 100 and 124 Kodak Jiffy 620 Kodak Junior Series II Kodak 2 Folding Pocket Brownie B Kodak 2A Brownie Model B Kodak Retina Reflex III Kodak Stereo Kodak Tele-Ektralite 600 Kodak Tourist Kodak Vest Pocket Autographic Konica FT Motor Mamiya/Sekor 500 and 1000 DTL Minolta srT-201 Minolta XG-7 Minox B Miranda Sensomat RE Miranda Sensorex Nikkormat FTN Nimslo 3D Nishika N8000 Olympus Camedia D-450 Olympus OM-2S Olympus Quickmatic EEM Olympus Stylus µ Pentax K1000 Pentax P3 Pentax Spotmatic Pentax Zoom 105 Super Pentax ZX-30 Polaroid Big Shot Polaroid Land 210 Polaroid Land 360 Polaroid Land 420 Praktica LTL 3 QRS DeVry Kamra Revere 33 Ricoh Singlex Ricohflex VIIs Rolleiflex Automat MX Rolleiflex SL35M and SL35E TDC-206QB Topcon RE 200 Toshiba PDR-M25 Tower 97 and Scout 120 Traid Corp. Fotron III Univex Mercury II Unknown digital camera View-Master Personal Vivitar Mini Digital Vivitar PN2011 Vivitar Vivcam T135 Voigtländer Bessa Voigtländer Brilliant Voigtländer Dynamatic II Voigtländer Vito B, C, and CD Voigtländer Bessy AS Yashica Auto Focus Motor Yashica Lynx 5000 Zenit E Zenit EM