Propeller-based security system: long-distance programming ?
Greg P
Posts: 58
I would like to retrofit my father's security system using a Propeller-based circuit (as a Christmas gift). The existing 25-year old system has been experiencing frequent false alarms. Attempts to isolate the defective window or door sensor have proven unsuccessful. The sensors are wired in series and more than one sensor is likely defective so debugging is difficult at best. If I use a Propeller to wire all door/window sensors in parallel to individual Propeller i/o pins I can both diagnosis which sensors are defective and add an additional layer of intelligence to the system. For example, the alarm system could be programmed to ignore sensor activation if not accompanied by activation of other sensors within a prescribed time frame.
My questions:
1) I would like to give him the ability to edit Propeller code from his own PC. Unfortunately, to connect the Propeller circuit (located in his basement near the alarm system) to his PC (two floors above), I must route the PC RS232 signal through existing wires to his attic then to the basement ... upwards of 250 feet !! While I know I can communicate with the Propeller at low 9600 baud rates reliably at this distance, I don't know if it would be possible to upload new firmware to the Propeller (and its EEprom) using the Propeller Tool software from such a great distance. Does anyone in the Propeller community know if the Propeller Tool is capable of long-distance uploading of new firmware ? If not, is there a work-around solution ? He does not have a portable PC so that eliminates one possibility. Could I program an additional Propeller to receive the "firmware code" via RS232 at 9600 baud, stored it internally, then have it program a second nearby Propeller which will actually be communicating with the old alarm system ?
2) Does anyone have a suggestion on how best to protect the input signals to the Propeller from lightning damage ? I will be using a fairly large value (100K) current limiting resistor, but is there a cheap fast acting bidirectional voltage limiting component I could add as well ?
Any help with these two question would be greatly appreciated ... especially the first.
My questions:
1) I would like to give him the ability to edit Propeller code from his own PC. Unfortunately, to connect the Propeller circuit (located in his basement near the alarm system) to his PC (two floors above), I must route the PC RS232 signal through existing wires to his attic then to the basement ... upwards of 250 feet !! While I know I can communicate with the Propeller at low 9600 baud rates reliably at this distance, I don't know if it would be possible to upload new firmware to the Propeller (and its EEprom) using the Propeller Tool software from such a great distance. Does anyone in the Propeller community know if the Propeller Tool is capable of long-distance uploading of new firmware ? If not, is there a work-around solution ? He does not have a portable PC so that eliminates one possibility. Could I program an additional Propeller to receive the "firmware code" via RS232 at 9600 baud, stored it internally, then have it program a second nearby Propeller which will actually be communicating with the old alarm system ?
2) Does anyone have a suggestion on how best to protect the input signals to the Propeller from lightning damage ? I will be using a fairly large value (100K) current limiting resistor, but is there a cheap fast acting bidirectional voltage limiting component I could add as well ?
Any help with these two question would be greatly appreciated ... especially the first.
Comments
For programming you can add an sd card and use my bootloader in the obex.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
Your best bet for remote reprogramming is a standalone app that transfers the byte from the PC to the Prop. You would need a method in the Prop to receive the chunks, and write them to the EEPROM as they come in. I recommend Real Basic for putting together such a stand alone app.
If you have the ability to get to the unit without a problem, you can get a VMUSIC2 or VDIP, and attach it to the Prop. You then could compile the program into a .eeprom file, drag it to the USBdrive, take the drive to the Prop and VDIP or VMUSIC2, plug it in and run a method on the PRop to update the firmware. As mctrivia just stated, you can also use the SD cards for updating.
Post Edited (Todd Chapman) : 12/21/2009 1:07:19 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm
www.lammertbies.nl/comm/info/RS-232_specs.html
The cable length mentioned in the standard allows maximum communication speed to occur. If speed is reduced by a factor 2 or 4, the maximum length increases dramatically. Texas Instruments has done some practical experiments years ago at different baud rates to test the maximum allowed cable lengths. Keep in mind, that the RS232 standard was originally developed for 20 kbps. By halving the maximum communication speed, the allowed cable length increases a factor ten!
RS232 cable length according to Texas Instruments
Baud rate Maximum cable length (ft)
19200 50
9600 500
4800 1000
2400 3000
The numbers above give me confidence that RS232 will work (with lightning protection). Also, note that serial Propeller code simply samples data at mid bit position. Any additional cable capacitance would tend to eliminate transients, the better for reliable detection. Only initial edge detection of the start bit would seem to be a concern.
Also, I have been looking at Chip's Propeller Loader v1.0 object. He provides a means of programming one Propeller from another Propeller. If the "programmer" propeller could be equipped with a serial object, it could simply copy incoming low-baud (<9600) data to hub ram then using the loader object program the "alarm system" Propeller. I could write a simple PC application that would send the contents of the .eeprom file, perhaps appending a checksum for confidence.
It would be nice if after the upload operation, the "programmer" propeller could revert to a default "relay station" for transferring low baud data back and forth from the "alarm system" propeller. This suggests that the "programmer" propeller should accept a special "P" programming command from the PC, but otherwise simply pass through data back and forth to the "alarm system" propeller.
Does anyone have existing code which performs this function ?
My father is disabled, so walking two stories up and down stairs to swap out SD cards would be difficult for him. The programming serial cable would normally be disconnected except for rare firmware updating operations ... reducing the risk of lightning damage. But while testing the new code, as you know, multiple uploads may be required in a short period of time.
There are objects to do what you require in the OBEX as you have discovered. I am assuming that you have a cog capable of communication serially, with the appropriate interface (RS232 is the easiest, although RS485 may be better for you situation).
Anyway, you will require a cog with serial comms and a cog to check the code received is valid.
There are OBEX objects that will program the eeprom. If you use a 64KB eeprom (AT24C512B) you will be able to program the upper 32KB as it is received. If successfully received (using checksum) then after it is programmed in the upper 32KB, copy to the lower 32KB and reboot - you can see examples of this in PropDos and Femtobasic.
As for lightening strikes, nothing is foolproof here.
What I used to do in modem designs was to have·series resistors (3-5 ohms 1/4W or less) and MOV's accross the leads after the series resistors. What happens is that an overvoltage will cause the MOV to activate and the resistor will blow. Usually, you just replace the resistors, so socketing them can be appropriate. Note I have still seen modems destroyed, but most were protected by this method. Strikes are usually > 7KV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
My objective is to avoid using more than 32K byte eeprom so that I can purchase one of the pre-assembled development boards.
Is this correct ? If not, please clarify. Thanks !
PS - The standard RS232 protocol can still be used with RS485 drivers/receivers.
Who makes this stuff up? I swear, the correct unit is MILES NOT FEET.
Who has DSL, and needs signal boosters every 25 feet?
Does the phone company boost their trunk lines every 50 feet?
Post Edited (VIRAND) : 12/21/2009 8:12:03 AM GMT
Only the required (used) section of the 32KB is actually loaded and the balance is zero filled by the prop object. You will need to check the object you intend using.
Should you stop the alarm code, then you could manage a different mechanism.
RS232 and RS485 are only electrical interfaces. The underlying software interface is now usually serial (asynchronous) although that was not always the case.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
PRO: no wires.
CONTRA: propeller tool would not work, since there is no means to trigger reset line via RF module. A special program would be needed. Greg, unfortunately, I do not use Windows anymore, and cannot help you with such a program.
DSL is not RS232C.
I've sent DMX-512 at 250,000 baud over 1km on three-core mains cable using RS485. That's not RS232C either.
I located an in-stock, $1.66, 8-pin DIP RS485 transceiver chip which affords live insert/removal, immunity from ESD & latchup, 4000 ft operation at 110Khz, low 300uA power consumption, and tolerance for up to +/-7v differential in transceiver grounds !!!
If I were to use three of these chips for the TX, RX, and RESET lines, I believe I could directly program the "alarm system" Propeller chip located +250 feet away from my Dad's PC. He has available an "old fashioned" RS232 9-pin port on his PC. I would just need to furnish a local +5v supply for powering a circuit with three LTC485 chips and an RS-232-to-TTL translation chip (like a MAX233).
Taking this approach eliminates the need to perform extra steps when uploading new firmware. No saving of eeprom binary files, writing a special uploader program, etc. !
A great bonus: the same TX & RX serial lines could be used by my Propeller application to send status information back to the PC !
What do you guys think .... will this approach work ? Thanks for your many suggestions.
search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=LTC485CN8%23PBF-ND
Digi-Key Part Number LTC485CN8#PBF-ND (8-pin DIP, 5v supply )
Quantity Available 3,654
25 Piece Pricing $1.66 each
Previous RS485 transceivers have been designed using bipolar technology because the common mode range of the device must extend beyond the supplies and the device must be immune to ESD damage and latchup. Unfortunately, the bipolar devices draw a large amount of supply current, which is unacceptable for the numerous applications that require low power consumption. The LTC485 is the first CMOS RS485/RS422 transceiver which features ultralow power consumption without sacrificing ESD and latchup immunity.
@ LTC485 is able to comfortably drive 4000 feet of wire at 110kHz.
@ 30ns Typical Driver Propagation Delays with 5ns Skew for Up to 2.5MB Operation
@ Power-Up/Down Glitch-Free Driver Outputs Permit Live Insertion or Removal of Transceiver
@ –7V to 12V Bus Common Mode Range Permits 7V Ground Difference Between Devices on the Bus
@ Low Power: ICC = 300uA Typ
Post Edited (Greg P) : 12/21/2009 4:02:36 PM GMT
WRONG!!
You don,t know anything about DSL.. DSL and Cable Co use a similar format The signal is NOT sent via a wire pair
like the phone or coax Cable tv! the signal is an RF signal which is sent as an overlay on the wire which don,t affect the phone calls.
And DSL dies off as you get further away,most one gets back in the earlier day,s was about a mile before it started to get real bad,ADSL was better but expensive.
now it's improved a lot, I think they solved the problem with how far with fiber optics ,run to a box close to home,the cable Co do it now,I get 20 + meg bps now!
Back when, I was using a 300 baud modem, back in 83 on my old Coco, them were the day's...26 year's,our Prop chip maker(Chip) should know He had one too
kind of like what we are doing with the Prop chip these day's.
Merry Xmas and to ALL a happy new year
Cheer's Dennis
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://people.delphiforums.com/cocokiwi/Image/picture.jpg
You should then be able to download and communicate nicely using TXD, RXD & DTR.
The only caveat on all this is providing the wiring is 'quiet' from interference.
As you mentioned lightening strikes, are these likely in your area. If so, I suggest using the resistors and movs at both ends.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Re:cocowiki
There is, in my experience, no un-obvious behavior whatsoever in wire at Low Frequencies.
Anyone who has electricity and a telephone mostly knows how wires work at LF.
An exception is Tesla Coils, which are made of wire and behave very strangely.
To RF, radio frequencies, wire is mostly like an antenna. For microwaves and Light, wire is mostly useless.
The Propeller may be the first common user-programmable device that almost steps over the limits of
obvious wire behavior, and I am only talking about its ability to broadcast video and receive AM radio
by using software, and these kinds of things. A 6502 is capable of high speed RS-232 and standard speed i2c
over long distances with software.
I have seen DSL over an ordinary telephone wire, split to a phone and a modem with a crossover filter,
and followed the telephone wire (one twisted pair) to a neighborhood phone box with No electronics inside,
but only a "block" that crimps together twisted pairs from homes, to ones from a thick bundle of them
which goes directly to the local central exchange. I have seen the DSL signal on an oscilloscope. It doesn't
really look like anything else but noise. I was shown this by a telephone company man within the last 9
years, who STILL does not know how to install fiber. I have rarely seen fiber, in fact only in a public
school network. This is within 100 miles of New York City, and I doubt that there is any fiber (in that
suburban town where the telephone man lives) outside of the Public School at all! The town does have public wifi though.
RS232 uses a single line for transmit and one for receive, with both signals referenced to a ground wire. That makes it more susceptible to noise pickup. It is also a voltage level (+-12V nominal) and the transmitter/receiver are fairly high impedance which makes noise even more of a problem. The standard also does not require twisted pair cables although they are used often now.
RS 422/485 is a 2 wire twisted pair with differential signalling so when one wire goes low the other goes high. The receiver is looking at the difference between the two signals, not an absolute voltage level. Any noise pickup appears on both lines and is canceled by the receiver since it is looking at the difference between the lines, not the absolute levels.
DSL is also a differential signal with data modulated on a high frequency carrier and sent over the twisted pair phone line. A filter separates the high frequency from the audio so a single twisted pair can carry both data and voice. I am sure there is a limit on how far it can be sent (2-5 miles I think) since I could not get DSL in my previous house because we were too far from the exchange.
Re:kwinn
If I run a wire from here to your house, and lets assume we each have our own pairs,
and I am sending data with one wire connected to digital ground and the other wire was going positive and negative in voltage,
and you are sending data using differential signals, with a second gate outputting just the other one inverted.
In that case, if we were ignorant of each other's outputs, how could we tell the difference?
Both of us would see relative polarity reversals on each wire pair.
It seems likely that each other's wire pairs would pick up almost equal amounts of noise that would cancel.
If there is a way to tell, an op-amp or two should prevent or remove that information.
If you can get the Propeller to transmit GRAPHICS to an ANALOG TV channel... WIRELESS-ly... (Challenging)
Then you can get it to transmit much further with a wire pair directly connected.
If it seems otherwise, try shunting the TV end of the wires with a 100 ohm resistor. (or use a balun)
That will make the Very High Frequency want to go to the end of the wire more than jumping off into space.
NO, DON'T DO THIS EXPERIMENT ON HDTV. STILL GOT THE OLD TUBE?
If you succeed, realize you are putting more than the equivalent of over 54Mbps of simple serial data through a wire.
Yes, I know, the TV only uses 4 to 6 Mhz of it, but the Propeller might make over 60 MHz go through a lot of wire.
Check out http://en.wikipedia.org/wiki/EIA-485 and look at the "See Also" section for RS232 and some of the other protocols. I have worked with serial protocols (RS232, RS422, RS423, RS485, and others) for many years and the limitations of RS232 are real. Under ideal circumstances the speeds and distances attainable may be greater than the specs, but in the real world they are reasonable limitations if you want a reliable system.