Most reliable way of prop-windows comms?
sumdawgy
Posts: 167
I'm reading various issues with buffering troubles over ip.
and serial coms I know from experience can loose synch.
So I'm thinking that photosensors mounted to spots on a dedicated monitor....
---used to transfer byte data
And a relay to click a few chars on kybd(temp hack).
at least this way both units can verify that the other is responsive.
I was also looking at maybe bluetooth? using an old android handset.using maybe RFObasic.
then I could have the win system talk to the handset. (or cut it out completely)
I want to be able to automate & monitor few home processes remotely..(end goal)
[in my dreams I would tie in my dishwasher & washing machine] then my wife kicks me.
I relize the question is a bit vauge but so is my info here..it's a bit spotty.
Can someone point me down a path...it doesn't have to be beaten. Just "safe".
and serial coms I know from experience can loose synch.
So I'm thinking that photosensors mounted to spots on a dedicated monitor....
---used to transfer byte data
And a relay to click a few chars on kybd(temp hack).
at least this way both units can verify that the other is responsive.
I was also looking at maybe bluetooth? using an old android handset.using maybe RFObasic.
then I could have the win system talk to the handset. (or cut it out completely)
I want to be able to automate & monitor few home processes remotely..(end goal)
[in my dreams I would tie in my dishwasher & washing machine] then my wife kicks me.
I relize the question is a bit vauge but so is my info here..it's a bit spotty.
Can someone point me down a path...it doesn't have to be beaten. Just "safe".
Comments
For longer distances, maybe you'd want actual RS-232 level transmission.
You could use shielded cable if worried about noise.
Bluetooth is also very reliable as it does it's own data verification checking...
Probably overkill for household use though...
I have a monitoring system I wrote in Spin that uses XBee's to transmit to my computer and I've found to be very reliable - it can save hundreds of samples (but almost never has that many) in RAM and resend them over and over again as necessary very quickly until they are acknowledged by my computer. I plan to eventually release it to the public, but that won't happen any time soon because I'm too busy right now. Right now it's set up to monitor my high school's solar car, but it can be pretty easily changed to do whatever you want. It doesn't do as much in the way as controlling stuff, though - it really only collects data. It has some code to control stuff (and acknowledge it), but I haven't really tested it yet.
You can also connect with an android application, GRENN.apk is the example we have posted. The prop has a bunch of button - definitions is a file, and when it connects, the android reads the buttn defs and dispalays them. Now when you touch a button, it sends a macro (simple forth script) and the prop does whatever you want. You can even edit the macro from the android. (But we didn't run very far with it, too many other projects)
If you want to be reliable with windows, you have to control both ends of the communication. (Windows it where it stumbles). Sal (the propforth author) wrote a serial handler for the PC side (called goterm, being written in the go language) and this makes communications VERY reliable. You could use that, or write similar in any language of your choise. C would be fine, but something interpreted (like python) might have troubles on the PC (being under windows). We mostly use linux to eliminate all the windows related issues.
Any of these options are no exactly trivial, but they are not hard.
Have to disagree with your assessment of ip and rs232 vs rs422/485. While rs232 has been in use much longer rs422/485 is by far the more reliable. The only disadvantage rs422/485 has when compared to rs232 is the requirement of 4 conductor cables for simultaneous two way comms. The advantages of rs422/485 are much better noise immunity, greater transmission speed and distance, and only needs a single polarity power supply vs the +- supply requirement for rs232. IP is a software protocol that can run over several physical implementations so cannot be compared to the rs232 or rs422/485 hardware directly. The error rate would depend on the physical medium, but the higher level software protocols would detect and resend bad packets.
I will be trying your android solution as soon as my Bluetooth module arrives.
I wasn't a huge fan of forth but It's not unwieldy either. so. more annoying (initially ) than daunting.
Altho I AM STILL getting used to prop spin in the first place.
I think he meant my initial thoughts.
Certainly there are embedded systems the world over using serial communications that have been working very reliably for decades.
Assuming the hardware actually works the only way for serial communications to fail is if the software at one end or the other gets confused.
Problems like "losing synch" are handled by using a sensible protocol over the line that allows both ends to regain sync and or recover from all kinds of other errors. Message headers with synch sequences, message lengths and checksums etc all help here.
You have total control over the Propeller end of such a link so that should not be an issue. At the PC end you alluded to Windows. The problems with your OS are somewhat out of your control there so I would be inclined to use Linux there.
In my recent experience with serial coms the biggest issue is with USB/serial dongles and all that plug-n-play USB software in operating systems that often does not play.
If it's hardware reliability you are worried about, all your proposed solutions look even less reliable to me. Actually building a systems that continues to work in the face of hardware failures is rather a challenge. Probably requiring multiple Propellers, multiple PC's and multiple serial links joining them all together. And some rather cunning software to handle failures of any part. For example read up on the Byzantine fault tolerance problem http://en.wikipedia.org/wiki/Byzantine_fault_tolerance. Such techniques are used by people like Google to keep their massive systems reliable. Perhaps rather more work than you need, it's all a question of the level of "safety" you demand.
well I'm not looking for distance so much as I'm looking for stable comms. Most likely my requirements will only be 50ft at MOST.
I was reading a few posts where the prop went into lala land while chatting with windows host. (due to lost packets & buffering)
I'm beginning to brainchild a home automation project... and a "walter mitty" prop will not do.
Using a USB serial connection, the prop is pretty much rock stable up to 230400 baud.Even with windows, if you have a modern machine. If you have linux any old machine will also do.
Blue tooth is also stable, I sent many meg of characters from the logger to the PC about 5 meters away and lost no characters (that I could see, all the records were intact)
I thing the problem (used to be) using a sub gigahertz PC wrunning windows, with lots of browsers and crappy scanners etc all fighting for the comms
Yes, I apologize for the vagueness..
This is more of a what path to take question..I haven't started down it yet.
Besides some initial musings in my notebook.
ALTHO, I am MOST appreciative of the various thoughts it spawned.
You all have given me 3 directions I'd not even considered as possible.
The house is already wired LAN to all 3 floors (*why I initially thought windows pc")
Since I'm passable all of the android basics (I think I saw an Android forth...
And, Android seems almost as stable as Linux IMHO.
I'll use one prop to handle all coms between floors and Bluetooth to handset which will be "main brain" and command interface(local & remote) The Bluetooth handset is something i like.. another mini computer easilly powered by 5vdc backup battery. I simply could tie the linked prop into the same backup. In the same case.
As to the fault tolerance ..Yes the Byzantine reference is EXACTLY my line of thought..although I didn't know there was historical name for it. Leave it to war, to create as well as to destroy, as usual.
I intend both systems to interact with polling and each have the ability to reset the non-responder. without me needing to interfere.
This is as UN-vauge as I can be at this time but...I am on a path with looks to be a hybrid of the ideas set forth here.....
That makes a lot of sense. AND explains the dissenting views too.
the props will be easy. They can reset themselves. Simple deadman timer that yanks on reset pin.
I'm just concerned that if the comms were constantly locking up the prop, nothing would get done.
It occurs to me that I'll need to start a new thread when this becomes more concrete and less about comm theory.
Just FYI: I have done this very thing. RFO Basic (aka: !BASIC) to communicate between an Android device and Prop. I used Class 1 BT adaptors and 115Kbaud @ 70yds worked flawlessly.
After reviewing the posts I think you are most likely right.
If anyone has anything to add, feel free.
I hope this thread helps others as much as it helped me!
Sorry, I just realized that my use of "any of those ideas" was confusing - I read Rayman's suggestion of RS-485 but forgot about it before I wrote my post. I have no problem with RS-485. I wasn't thinking about RS-485 when I wrote that post - I was only talking about not using blinky screen pixels in front of CdS cells and the keyboard/relay trick.
EDIT: read the rest of the thread: Yes.
Sorry about that. The initial post and your post were open to misinterpretation, and I certainly did that.
If you already have the house wired for ethernet you may have a head start on your project. Ethernet cabling consists of 4 twisted pairs, and 10Mb/s and slower hardware uses only 2 of those, so you may be able to use the other 2 pairs for comms. This is not a new and untested idea. Quite a few office buildings used the cat5/6 wiring to provide both ethernet and phone lines to the offices and cubicles.