Massive project for temp. and i just heard of picaxe

kranenborg

Senior Member
Hello b** and others,

I just learned about this thread and the fact that my SerialPower concept is proposed as a possible solution (but with some challenges to be addressed at the hardware side).

For the discussion here it is maybe indeed good to point out that the SerialPower concept integrates two - fully independent - aspects:
1: The software aspect: A network protocol for regulating messageing between communicating processes (in this case relatively simple since you need only one process per node) with avoidance of message collisions.
2: The hardware aspect: Solution for power and data over two lines.

Regarding the software part I would say that SerialPower would fit very well and would be very easy to program and test for this very interesting and practical app. You can even develop/test/prototype the software on a small scale on the simple diode-mixing network version as discussed in the SerialPower thread regarding the updated SerialPower II code for M2 processors. Next you could switch to the power+dataline version hardware by just switching the "SimpleDiodeMixing" flag in the code. You can use any of the discussed ways to assign an identifier per process/node. In fact SerialPower might be "overkill" in a certain sense since in your application all the nodes have to send only to a single master, so you could use the node identifiers as qualifiers used by the master by the SEROUT command. However, the SerialPower software has all of the communication timing already implemented for a fully distributed system and - most relevant for your system - is much more flexible since the slaves themselves can "choose" an ID (as long as it is unique, of course) as they are roamed for and then registered just after the network has been powered up. Any ID will work as long as it is a byte value between 10 and 254.

Regarding the hardware part I have to remark that I never intended the current hardware solution (either separated or combined data & i/o) to be used on such a scale (or better said, never thought of in detail), and several people here have pointed out the issues. However the suggestion by graynomad today (post #78) to combine the SerialPower software protocol (i.e. point 1) with RS485 (which is an electrical standard only, it does not say anything about the software protocol used, so it addresses points 2 well) is most interesting and would significantly increase the usability and relevance of the whole SerialPower concept. I will therefore definitely try to dive into this issue, hopefully some other members can as well in order to see whether we can find a simple, cheap but also reliable system (In the end it is always the non-functional engineering aspects that create the greatest challenges in realizing a working system)
Thanks for your interest, I'll return asap.

Best regards,
Jurjen
 
Last edited:

Paix

Senior Member
I am following this thread with great interest too.
In 1987 I used a pair of RS232 to RS422 chips to connect two terminals at 9600 baud between sites 1.5 miles apart successfully. RS485 is the smarter brother of course.

I don't know what decisions you have made regarding the comms protocol, but suspect that you may opt for the master to address a slave/sensor and await a reply data message from the device prefaced with the slave identity. The message is of fixed/limited length, so enough time is allowed for the response before addressing the next slave. Depending upon the frequency of reporting, the slave can either make the reading and report after being polled by the master, or it can report back directly and then make the reading ready for the next call. Obviously if readings were being made once in ten minutes then the former would ensure that the data was time-expired in any way. The second suggestion would increase throughput.

This speak-only-when-spoken-to scenario saves having any problems with collisions. Essentially you ask a question and expect a prompt reply, after which you only wait so long for the response and then move on, so an appropriate serrxd timeout parameter would be of use to prevent lockups and any non response might usefully be taken to indicate a problem with the appropriate slave rather than just a cold bearing check - same display perhaps.

Enjoy your shore time and good luck with the project.
 

kranenborg

Senior Member
Hello Paix,

Your "speak-only-when-spoken-to scenario" is a very good description of what I had in mind when i suggested the use of a "qualifier" (i.e. ID) as sent by the master; this addresses the proper master. SerialPower avoids message collisions by assigning each ID a unique timeslot during which teh addressed process may reply if needed/wished.

"you may opt for the master to address a slave/sensor and await a reply data message from the device prefaced with the slave identity": this is exactly what the SerialPower protocol does.

/Jurjen
 

Paix

Senior Member
@Kranenborg, I accept what you say, but have to admit having not having digested your SPp (SerialPower protocol) thread at all so am unqualified to comment, but see it possibly as a final solution and not one that would be om my breadboard initially.

My thinking would have me breadboarding a single master and slave with simple wires, in order to prove my basics were working as expected before growing the solution in my intended direction.

I'm not entirely sure if I would use SPp at all, but do think that it sounds attractive. Perhaps I would think not about scaling to 64 (56) nodes, but to four strings of up to 16.

But perhaps we are in danger of hijacking a super thread and should you wish to promote SPp then could I suggest starting another parallel thread to demonstrate the particular application to a project such as this. That would allow the communications and the ship master/slave project to travel together but apart so as not to overshadow each other, if that makes sense.

Now, I have to read your original thread properly to understand what's involved and how much of an overhead it represents in my mind. Not something that I had originally planned to be honest. :)
PS I'm very much a Picaxe lightweight.
 

kranenborg

Senior Member
Hello Paix,

I understand and agree with your remarks and in hindsight it seems that I got a litlle bit "taken away" and thus may have given the impression that I just wanted to promote the SerialPower concept. I actually meant to reply on b** remark in post #79 ("I did get concerned about the serialpower not being a reliable solution") having concluded that he already had decided on using this concept. I agree that the discussion should focus on the project undertaken here, so lets take care to do that (and I will continue the SP and RS-485 discussion on the SP thread instead since it fits best there). I am actually most interested to know more about the details behind your succesful 1.5 miles implementation since it may be most relevant for the project here as well.

/Jurjen
 
Last edited:

moxhamj

New Member
Re "speak-only-when-spoken-to", this represents a challenge with the older picaxe chips because:
1) The slave node is going to be waiting with a serin hang for the master to provide a signal and
2) There would be a real advantage to having the local nodes displaying the three color lights depending on the temperature.

One failure mode with the above would be that the master node stops working, so the slaves continue to show their old temperature and meanwhile the bearing is catching fire.

BUT...

Manuka recently pointed out in a recent email to me that the new picaxe 08 chips and friends support Serin with a timeout.

A timeout makes this problem trivial to solve. Read the sensor. Update the leds. Wait for the master for n milliseconds. Repeat.

I don't know if this changes any protocols with kranenborg's network?
 

ciseco

Senior Member
Dippy, it's 493, it's quite a new thing ya know ;)

I have missed your comments, you always make me giggle

I've not read the entire thread, has anyone suggested a sting of DS18B20's and bit banging, entire solution could be done with a single picaxe
 

fernando_g

Senior Member
All of you have your historical facts wrong.

The concept was first discussed in Republic of Genoa during the Renaissance.
Cristopher Columbus, being a Genoese, brought that concept with him on his second voyage to the Indies.

The Mayans were quick to adopt it, as it is clearly shown in the Dresden Codex.

The concept spread quickly across the New Spain territory during the colonial period, and flourished during the first years of the Mexican Independence.
The main research lab was located in a place called "El Alamo" in the small town of San Antonio de Bexar, which was destroyed during the Texas rebellion.

When Texas was annexed by the US, research was moved to Central Florida, where a century later the Walt Disney Company perfected it to create animatronics in Orlando Park.

There, you have the straight facts...Wikipedia, eat your heart out.
 

ciseco

Senior Member
Shucks, you are right, how can I have forgotten. 493 years ago I now remember was when one of the moderators was born ;)
 

Paix

Senior Member
I've not read the entire thread, has anyone suggested a sting of DS18B20's and bit banging, entire solution could be done with a single picaxe
No, but to paraphrase Hippy and Dippy, Let's see your your circuit diagram and code, scalable to 56 bearings.

= = =
Manuka, I had overlooked the timeout at the slave end, but remembered it at the master in the event that a slave failed to respond. I was thinking 08M2 slaves though. Thanks.

With regard to Bullehead67's post #65 proposal. slave ID setup using jumper or DIP switch selection.
http://www.picaxeforum.co.uk/showthread.php?19475-Massive-project-for-temp.-and-i-just-heard-of-picaxe/page7

Would a SN74LS165 PISO shift register, or equivalent, be a good choice, with Load/Shift and clock being controlled by pins C.1, C.2 and the ID being read bit by bit bit0 through bit7 from the QH output as the switch data is sequentially shifted and made available to pin C.3 of the Picaxe 08M2 as part of the slave power up initialisation and when complete stored to a less volatile variable?

The next thought is how to safely double the use of the C.1 and C.2 pins to look after an RGB LED once the slave is in it's listening, temperature reading and reporting The 74LS174 parallel inputs A - H being pulled up to Vcc by 10k, or higher, resistors. The data being presented serially on QH in the order H, G, F, E, D, C, B, A.

The pins Serial In, Serial out and C.4 (DS18B20) are already committed.

74LS165 Datasheet

Given the proposal cited by Bullethead67, is there a better device or way of reading 6 to 8 bits of data from links/switches given the availability of on input pin and two i/o pins?

Has anyone any idea how often the set of readings should be updated, given that there are 56 in the set?
 
Last edited:

ciseco

Senior Member
You obviously have concluded it cant be done, which I'm afraid I don't agree with and niether do datasheets. It was a mere suggestion, no more no less. I personally would do such a thing wirelessly.

In your first post "I imagine at some point i will be using a Xbee or Picaxe.net unit? is that right?"
And a lead acid battery on each one to keep the thing going for more than a day or two

There is an xbee sized module we design that'll do a few million transmissions on a single coin cell which might suffice your needs, you could have a delivery midmorning and have the whole thing running by lunch, doing it the picaxe route and xbee's would cost you around 3 times more and be poor on batteries. An xrf can pop up and transmit and sleep again 7 times in the time an xbee only wakes and syncs to it's peers.
 
Last edited:

Dippy

Moderator
Are we still talking about use on board a ship with 73 metres and a pile of steel bulkheads and metal things or are we on to something else now? The only wireless I can see penetrating that lot is the pi-meson NFSK method.

If you want address switches per node why fiddle around with an 8pin + periperhals? Why not use a PICAXE with more legs?
A useful thought exercise maybe but why make life difficult for the OP?

Actually I was born 873 years ago in 1904 to parents who were dyscalculic.
 

ciseco

Senior Member
I guess you didn't know that XRF's can be switched into bridge mode via a software command, simply place one on each bulkhead (at worst 2), or you could build an IP to RF gateway and wire it in zones, where there's a will and all that, only snag is we only have code for ARM and Arduino, nothing for the PICAXE I'm afraid, seems only one shield is listed and with no instructions I guess the axeweeny's are as popular as you thought they might be, anyone wan't an Amicus beer mat :D

873, wow that's a lot of birthday cards ;)

How you doing these days, is the new job going well?
 

Dippy

Moderator
Fell asleep driving home last week. Caused by a long and boring 3 hour discussion on MOSFET AC Bridge driver deadtimes. Deadtimes are deadboring.:(
 

hippy

Technical Support
Staff member
I'd also be cautious of using wireless on-ship with massive steel bulkheads and spinning radar things close by but I've no experience of such things so that's just gut feeling and fearing the worst.

Perhaps the best argument would be that if one has to run power to each node then one has to use a cable for that and it's a fairly simple matter to use that for data comms as well.

I'll agree, a wireless system would be very elegant, especially one in a mesh / relay configuration, but it's a level of complexity that is quite high for a PICAXE newcomer. I'd also say that two-wire data over power networking may also be too complicated if four-wire can be used and that allows the comms and software to be simplified and lowest cost components to be used.

Just daisy-chaining DS18B20's on a 1-wire bus with a single master PICAXE was suggested but I wasn't sure how that would hold-up under the practicalities of long runs given its high-speed nature, that radar and other potential interference.
 

John West

Senior Member
<snip>
Has anyone any idea how often the set of readings should be updated, given that there are 56 in the set?
With their mass and the ability to set reasonable alarm threshold values before a bearing reaches a failure point, I'm guessing that one update per bearing every few minutes would be sufficient, so there's time to do reasonable polling of single function slaves. But that is just a guess. When BH posts again, I'm sure he can update the info and let us know what he sees the requirement to be, as that would drive the polling method.
 
Last edited:

John West

Senior Member
An RF solution would be convenient and could be quite elegant, but I'd avoid wireless entirely in this application. It's a high-rel desired system in an environment that is likely full of EMI, from motor spikes to shipboard radio and radar. Toss in the possibility of the transceivers interfering with shipboard electronics and the possibility of large metallic equipment being moved around ship and blocking the transceivers RF path as well.

Too many detrimental and unknown variables. Just not a good environment for RF links.

The RS485 chips I offered BH have a high ESD rating that I figured might be necessary even in a hard-wired shipboard system. It looks like a well run ship, but there's no such thing as over-kill in the electronics for such a work environment.
 
Last edited:

hippy

Technical Support
Staff member
Has anyone any idea how often the set of readings should be updated, given that there are 56 in the set?
As with John West my feeling is that there's no real urgency as bearing temperatures aren't likely to soar and ( without looking back to check ) I think it's an 'every hour' manual check now.

As to how quickly the bearings can be read - Whether multi-drop 1-wire direct or multi-drop serial to nodes, they should all be able to provide data in a staggered manner within a second. A PICAXE node can deliver its last reading and take the next ready for when it's asked again so it has a reading ready for when asked. Nodes can still be read once an hour or whatever, just ask for the data then ask again a second later so it's not data which is well out of date.
 

Paix

Senior Member
@Dippy, yes, trying also to run a RGB LED (with two wires!) from an 08M2, I figured that I was well up the creek trying to squeeze more pins out of an 08M2 than it has and opting for a complication and extra expense by way of the SN74LS165.

A 18M2 with pins to spare seems ideal (the 14M2 is a couple of pins short).

B.0 thu B.7 would read 8 DIP switch positions during slave startup - 10k pullup resistors..
C.2 DS18B20 sensor, C.3 serial out and C.4 serial in.
C.1, C.0 and C.7 can handle the RGB LED (three wires).

Each slave would require a DS485 chip to connect RS485 trancievers to the cable. Not sure how similar it might or might not be to Cat-5E cable, but a pair each for transmit and receive. The tranceivers are complementary push-pull and (extra 18M2 pin c.6 for T/R swiching . . . !) the receivers are differential receivers with high common mode rejection which will be more than capable of driving the length of cable (twisted pairs?) and spare pairs can be used to carry 12V DC from the Master unit and regulated at the slave units..

I had somehow forgotten how the zip, zip, zip of rotating radar antennas can get into things, so hopefully the RS485 and a little ferrite here-and-there, if necessary should be OK, thank goodness for all that steel . . .

Other than the polling and listening for slave responses, I haven't given an awful lot of thought to the Master unit, as yet, but I'm sure that others have. The thread continues to be stimulating. Sorry if I witter on a bit.

With temperatures here falling noticeably over the last few days, maybe I should think about running a few sensors in the domestic environment.
 

manuka

Senior Member
Ciseco kindly sent me a CC1110 based ~868 MHz XRF pair (which I confess still have to have a REALLY good workout), & they're indeed very impressive performers. Although a typical ship's engine room is a metallic nightmare, they may just cut the mustard enough to "bounce signals between bulkheads", especially if a bridging repeater mode was chosen. They're certainly cheap enough (~US$15) so maybe worth a trial ?
 

Paix

Senior Member
It would just be like it to get everything working on RF and someone would come along and shit a steel door . . . Mr Faraday, eat your heart out.
 

hippy

Technical Support
Staff member
They're certainly cheap enough (~US$15) so maybe worth a trial ?
56 x $15 = $840 = £540

It soon adds up, though that's probably loose change to a business or when it has a demonstrable return on investment.

Likewise everything adds up, which is why I'd be inclined to go as simple as possible, diode-mixed multi-drop serial if possible rather than RS485.
 

John West

Senior Member
It would just be like it to get everything working on RF and someone would come along and shit a steel door . . . .Mr Faraday, eat your heart out.
I've read great things of Michael Faraday, but I'm sure that's something not even Mr. Faraday could do.

I must say, this thread is very interesting.
 
Last edited:

manuka

Senior Member
It's a tad before even my time,but Michael Faraday apparently eat steel doors for breakfast,and for lunch he nibbled on bulkheads.

The kind of ball park figures Hippy has tossed around indicate (again !) to me that a passive IR imager should be at least borrowed & evaluated. Even if it IS "stolen" -which is a tad hard to credit when deep in a ship- it'll surely be an instant productivity booster. Rather than peering into dark interior spaces the guy doing his hourly bearing checks could be also employed as an on deck look out.

This latter duty is considered particularly relevant here in NZ at the moment, as we've just had a huge container ship run hard aground on an offshore reef in dead calm weather. Local seafarers are astounded,as the reef (which has been well known & charted for ~200 years) is so piddling (football pitch size) that such a vessel could hardly hit it if trying to!

I've been following the "Rena"'s AIS woes ( via Marine Traffic) & note wave action is shifting & grinding it's hull- pundits are already considering it both an environmental disaster AND $$$$$$$$ writeoff.
 

Attachments

Last edited:

bullethead67

New Member
Time to buy something

Lots and lots of posts while I was in transit. Well I'm home now. We seem to be discussing RS485?

That would be a new direction and I think we need to start buying parts or it will just be pulled in a hundred directions. Of course there are 100 valid directions to go.

I really do like the wireless route but have not looked into it as I am beyond my limits now and fear it would pull me further into unchartered territory. Please try not to forget that I am reliant upon the assistance of others. There is no way around this in my limited timeframe. I now have 29 days to at a minimum purchase all parts etc. If shipping is considered that time may be cut by 7. I assume a error or 2 will find it's way in and will require resolution. This is more time.

It is time to purchase parts.
Dip switches will be omitted as I need to move fast.
Is there a serial power pcb layout available I can send to a quick turnaround shop.

Any suggestions for purchasing?

Keep in mind this is for the prototype and the final if approved would most likely be different. In a nutshell it is a "can I have money for this". I expect the presentation would center around the display panel. No electronics techs just a manager. Mabye just a report sent to a manager.

On a side note im putting in a order for a picaxe.net kit. I'm going to hold it as my last ace.
 

John West

Senior Member
BH67: Note my post #80.

The RS485 just indicates the specs of a differential communications driver chip that would seem appropriate for the electrically noisy location of your proposed data gathering network. They are neither expensive nor terribly complex to use.

Here's a one page tutorial that sums it up pretty well:
http://www.lammertbies.nl/comm/info/RS-485.html
 
Last edited:

ciseco

Senior Member
Just penned 3 paragraphs, database error, all lost, I see vbulletin is as steady as ever, I doubt our use of kunena is any better, no critisism just a little frustrating. Those autosaved pop ups didnt rescue it . Oh well

@hippy, I dont agree wireless is complex, used to be perhaps, now things are better for the novice TXer. For example using LLAP requires no knowledge what so ever, I could give you a USB dongle and temp sensor and with no setup at all and just windows hyperterminal you can pull temp readings in, in just a single text command a--TEMP----. Set the thing to auto send and they just come in, you can sit there and just watch the data arrive on the serial port. Getting 56 running is a matter of giving 56 addresses, you send a command like a--CHDEVIDAA to change a new device ID "--" to have ID AA. Would take a few minutes to do all 56 but thats about it, then you can poll them with aAATEMP---- and they'll respond aAATEMP+25.5 or similar. There's even a version I popped up that uses an 08M to do something similar, there's not enough space for CHDEVID command on an 08M, so ID needs hardcoding. I have 28x code that suppports LLAP much better. By this approach you can do it serially via wires on el boggo RS232 or with RS485 or an Xbee or XRF, indeed anything that allows you to do serial you could use, powerline modems, modem modems (anyone still got one), anything as long as it's straight standard serial.

£540 sounds great value for a solution in a day, I guess it can be done cheaper by devoting weeks/months at it, depends if the challenge is reward enough to save perhaps half the cost

The "I wouldn't RF in a tin can" and radar comments.....I assume you guys turn off your phones etc in this mission critical environment, come on lets be serious, that's scaremongering the poor guy. Only way to know what the outcome is, is to try it. The XRF for example has a 14 day money back offer, if it doesn't work as you'd hoped, return it, don't like the colour, return it, wind blowing too hard, return it, the reason doesn't matter, what's to lose, nothing but the postage. Are we confident in our product, you bet we are. To date we have never had one back with a request for a refund.

I too think there's probably a better solution to be had by wires (pile more effort required tho), but the suggestions I feel are less than optimal. There's two things that come to mind that offer much better solutions than diode mixing, LIN & CAN. Both were designed with harsh vehicular environments in mind, good enough for rolls royce! I personally like LIN, it's also arguably 1 wire, the transciever chips are about £1, with a standard LIN frame you can send 8 bytes (enough also for LLAP). There's a chinese company that does xbee shaped LIN or CAN modules (can't remember which) so there's all the kit out there to even proto the idea on a PICAXE without even getting a soldering iron out, just axeweeny of choice and the module + shield.

The world has moved on.......times, they are a changing (in my best dylan voice), when is the advice given going to reflect it :)

Did you know our radios are actually micros? If you know C or C++ you can program them for free, there's 16 odd I/O pins on the module, 32Kb RAM, and they run at 26Mhz, more than a match for a 28xX, and cost, about double (that's mostly because they are built in low volume in the UK). In Q2 next year there will be for less than £2 a 32bit Arm based micro with built in RF coming out, it's also got a built in temp sensor, uses 4ma in continuous RX. The PCB and battery to power it might cost more. There are discussions of porting one of the opensource languages to it already and we are porting LLAP to it. Now, £5 for an 8 bit top end picaxe or £5 for a 32bit module with 30 odd pins of I/O, every peripheral available and a top spunk radio. I once questioned why not run PICAXE basic on our modules or similar...........still waiting.

Picaxe.net, try a search for nanode.eu, people have already got LLAP running on it, how about the tweeting mousetrap or publishing to patchube, it's all out there free to cut and paste. I think somewhere there's even a LLAP via XRF to wifi so that's straight to your PC or phone.

Second verse....times they are a changing :)
 
Last edited:

buntay

Senior Member
hey bullethead67.

I live in North Dakota and I would suggest http://www.sparkfun.com for purchasing parts. consistently takes 5-7 days for delivery up here. May be less for you since you are closer.

good luck and keep us posted
 

ciseco

Senior Member
To convince hippy it's not difficult doing wireless (just 6 lines of code). Here's a bit of a hack of the 08M temp sensor code from the snippets section. On the same PCB / breadboard layout etc. Here's how to poll and pull in a reading from a LLAP sensor using an XRF connected to the pins shown in that example, ie XRF DIN pin to axe pin 3, DOUT to pin 4. That's it just 2 wires + power, no other connections are needed

high 4
main:
serout 4,T2400_4,("a--TEMP-----")
serin 3,T2400_4,("a--"),b0,b1,b2,b3,b4,b5,b6,b7,b8
goto main


' variables b4 to b8 have the temp value in them as text

Sleep and flow control are also easy to do by a single pin each. Flow control is really useful on the baby AXE's which don't support non blocking serial commands, means you can pause serial reception go do something come back un pause, recieve and carry on.

Making the axe a proper controller is dead easy - example: a boiler thermostat in logic using a LLAP temp sensor and LLAP relay (both could be picaxe devices)

start
serout "temp"
serin the value
is value over 21C then send "relayoff"
is value under 21C then send "relayon"
repeat

Thankfully LLAP message are just 12 bytes long so can fit entirly into the b0, b1 type variables available on even the baby PICAXE's
 
Last edited:

Dippy

Moderator
"...I think we need to start buying parts or it will just be pulled in a hundred directions."
- too late! :)
This is always the problem when we have 50 experts contributing - sadly none of us are experienced marine engineers and none of us have experience in ship-based data comms.
It's not really a good idea to over-promote a medium without testing or evidence - regardless of how big the micro is.


Why not list the Pros and Cons of each?
Example.

RF.
Advantages.
1. Ease of installation.
2. Cheaper to install.
3. Easier to move or expand system.
Disadvantages.
1. Potential unreliability.
2. And glitches may require a local reset. Pain.
3. Repeated unreliability will cause operator to swear a lot and give up.
4. Parts cost; I suspect you may need X x 56 RF nodes to form a reliable network.
5. More gubbins to go wrong.
6. More complexity for someone not experienced in RF (installation and operation).

Wire.
Advantages.
1. Good installation will provide excellent reliability.
2. You would have to wire for node power so adding a comms wire is no problem.
3. Can be designed to ignore EMI/RFI interference.
Disadvantages.
1. Installation cost and time.
2. Some areas may be very difficult to cable.
3. Poorly designed driving or unsuitable cable caused by penny-pinching could cock it all up.
4. Physical damage to a single cable could bring it all to a halt.


As I don't have a commercial interest my personal opinion for a permanent fit-and-forget system would be wired in conduit with suitable drivers.

I haven't got a clue how RF would behave with all that metal shielding/reflectors kicking around; I suspect no-one here has? It could be an expensive and time-consuming mistake.
And if installed by someone with no RF experience then you add another layer of potential error.
Without a 'proof of concept' with a pile of RF Modules I reckon we would be heading into fingers-crossed territory.


Maybe combine the wired and wireless?
Wall mounted transceivers with a little extra firmware could join cabled sub-networks in places where cabling is impossible or impractical. This would require simpler RF comms.
Maybe each sensor could be battery powered to a wall-mounted RF transceiver. Expensive though.

For your Demo I would have a few sensors joined by simple cable to a master on a big square of hardboard painted nicely.
Keep the demo simple and reliable.
Don't waste money and time on fancy interfaces that are beyond your skill-level at this stage.
The operator/owner may just say No....
 
Last edited:

kranenborg

Senior Member
Hi,

Motivated by the information I got from Paix (in a PM), Graynomad and others in this thread I myself also dived into the RS-485 area, previously almost unknown to me. What I like about a wired solution is the simplicity of checking things; you can easily check whether power is there at a node as well as the voltage levels, and with a logic probe or someting similar you can also check whether there is communication. Last but not least, sticking to standards like RS-485 is a recommendation for a project like this.

The things I noted after some RS-485 research and having visited the electronics shop website and store, for what it is worth:
- The twisted-pair cables needed for RS-485 never seem to come as a single pair, even the cheapest cable has several pairs contained in it, which means that it is very straightforward to carry power and data separately and thus to feed the nodes power if they do not have it locally (which may be a huge advantage regarding cost and replacement/monitoring mantenance?). The ohmic loss per twisted pair for the cheapest cable I found was 180 Ohm per kilometer, and by parallelizing you could bring that down if need. All in all the voltage drop would be small. Furthermore as Paix suggested the voltage level in the cable can be kept somewhat higher (12 or even 9V) and at each node be brought to 5V with a simple regulator (as an extremely simple solution at the prototype level) or maybe a buck converter for max. efficiency. So all in all no complicated combined power & data solution needed, whatever the software communication protocol (Serialpower or not) applied.
- There is indeed a plethora of RS-485 tranceivers available
- If found much information of interest on RS-485 at the Maxim website in the form of application notes, particularly here: http://www.maxim-ic.com/products/interface/rs485_resources.cfm
- You may maybe want to defer the final decision on RF or cable by making two prototypes, each with only two nodes? You could then test the stability of RF transmission yourself before ending up shoehornded into a particular implementation.

B.R.,
Jurjen

PS, now saw the excellent contrib by Dippy, I agree with his message
 
Last edited:

ciseco

Senior Member
@ Dippy

RF.
Advantages.
1. Ease of installation.(often)
2. Cheaper to install. (often)
3. Easier to move or expand system. (often)
Disadvantages.
1. Potential unreliability.(subjective, based on what, it's more chance to be more reliable than something homebrew)
2. And glitches may require a local reset. Pain. (buy stuff thats been disigned for it rather than make it)
3. Repeated unreliability will cause operator to swear a lot and give up. (trial it first)
4. Parts cost; I suspect you may need X x 56 RF nodes to form a reliable network.(depends)
5. More gubbins to go wrong. (totally disagree)
6. More complexity for someone not experienced in RF (installation and operation). (totally disagree, perhaps that phone in your pocket or your bluetooth headset should only be operated by people "experienced" in radio, where does the perpetual "I don't know, therefore you'd better not even try it" come in and persist around here, this is the very reason I got into this lark, it's people saying because I dont know it's surely not possible that drove me to build what I couldn't buy)

Wire.
Advantages.
1. Good installation will provide excellent reliability.(requirement of something tried and tested and experience, neither apply so cant see that as an advantage)
2. You would have to wire for node power so adding a comms wire is no problem.(agreed)
3. Can be designed to ignore EMI/RFI interference.(not to be the case at a novice level, I have recent experience of someone unable to sort EMI/RF issues)
Disadvantages.
1. Installation cost and time.(agreed)
2. Some areas may be very difficult to cable.(agreed)
3. Poorly designed driving or unsuitable cable caused by penny-pinching could cock it all up.(almost inevitable)
4. Physical damage to a single cable could bring it all to a halt.(very good point)

I see neither of you mentioned LIN or CAN yet it's a multidrop network similar to 485 yet actually designed with such environments in mind like very high immunity to ESD, find a datasheet.

The truth is out there...........

Just be careful of the sign posts you read, seems often they all point to mandalay.

The times they are a changing :)

@Jurgen, we have never spoke so I'll be far less tonge in cheek than I am with the dipster, both of us love to stir the pot. You make a very very good point "You could then test the stability of RF transmission yourself before ending up shoehornded into a particular implementation."

This is perhaps the single best reason for even attempting wireless, you can find out in minutes if it stands any chance of working by walking around with some test kit, with wires you could spend days/weeks doing little sections and the final switch on go fuutt.

I still think wires is the way to do it properly, however something from the ground up on kit never seen in 29 days, that will remain reliable and is afterall a protection mechanism.....well the reasons answer my doubt, I wouldn't quote for the work on that basis, so slim would be my expectation of it being delivered. If the guy had many months to tinker it would be entirly different. I suggest looking at things like MODBUS, it's proven technolgy if 29 days is the real deadline, the price is very very much higher but will work without question.
 
Last edited:

moxhamj

New Member
29 days to get how much working?

Soldering up a picaxe with 3 leds and a LM35 could be done in an hour or two but I suspect for demonstration purposes it will need a bit more than a single PCB?

Ok, I'll jump in with some specs.

If I had to do this, I'd go for cat6 cable because it has 4 twisted pairs and is not expensive and all the crimp joiners are easy to use in the field.

I'd be using RS485 and run a full duplex system, which means one pair for Tx for the master to ask for a reading from a node, and one pair for the common Rx line which all the nodes reply on. Picaxe plus 485 chip is going to be under $10.

Use the other two pairs for power and maybe parallel them up. I'd be tempted to run something like 24VDC with local switching regulators, as all the leds are going to add up to a fair amount of power (20mA x N nodes). The LM2575 is good value.

For the cable and the proper rated boxes, I'd outsource that. The people who run conduit around the place are experts. Each box has cable going in, cable going out and a cable to the temperature sensor.

The board cost could be $20 -$40 per board and will be a pretty simple design - RJ45 sockets x2 and I'd probably go for screw terminals for the temp sensor, and the three leds. Or maybe set the leds up on the board so you could mount the board on the inside of the cabinet door. It would depend on the cabinet and in general you don't want to be drilling holes in it as you want it waterproof/moistureproof.

The 'proper' solution would be a picaxe board in a box that mounts on a DIN rail, as there are off the shelf cabinets with din rails in them. I think stocky has built those sorts of boxes.

Just my 2c worth though.

I did have a thought the other day about this. Regarding the master node and any display you might have, you can think of all sorts of fancy displays, but you don't really need to see the temperature of every bearing. All you really need to know is the temperature of the hottest bearing. That is the one you need to know about. So just display that temperature in degrees (a dual 7 segment display will work fine) and the node number (another dual 7 segment display). Any of the bigger picaxe chips will be able to run the displays and handle the polling.
 

ciseco

Senior Member
You are right about needing to know the hottest (unless the conditions change upon location of each bearing)

On the gui side, I'd not have one, data log it and have 56 rules, if bearing A exceeds temp then send me SMS/email/sound siren/flash a light etc. This is something like Monnit can do and it's off the self, with our stuff we have SMS/Patchube/twitter/email examples, but none are for the picaxe as they all depend on ethernet being driven (I guess no one ever progressed the wiznet shield port), doing the sounder/flash could be achieved in just a few lines of code and 56 lines of if statements on an AXE, this would be trivial.

Aside from the obvious no on has mentioned a stitch of code to glue it together, the guy has said 29 days solution needed, what he has is 12 pages of conversation. I guess this is why my views are so wildly different from others, we do.......they talk
 

nick12ab

Senior Member
all the leds are going to add up to a fair amount of power (20mA x N nodes).
A simple R/C astable could be used to strobe the LEDs (maybe in turn using 4017 etc) and use lower value current limiting resistors in order to reduce power consumption with minimal impact on brightness.
 

Paix

Senior Member
RS485 Quick guide
http://cds.linear.com/docs/Product%20Selector%20Card/RS485%20Quick%20Guide.pdf

RS485 Transceivers sustain 60V fault condition
http://cds.linear.com/docs/Design%20Note/dn203f.pdf
http://cds.linear.com/docs/LT%20Journal/LT1785_0699_Mag.pdf

videos
http://www.linear.com/products/interface?gclid=CMqb9paH4qsCFQJO4QodXA9EPQ

Originally standard RS485 devices had/have a 32 node limit, but the electrical standard has proved to be very popular across a broad range of communication applications and this has brought with it a large number of improvements from a number of manufacturers competing to sell a better mousetrap.

In my searching I have looked primarily to meet the following criteria.
Low cost; enhancements are a cost on the manufacturer so bomb proof single chip solutions don't come in at the same price point as lesser devices, but some mfrs lesser devices are more advanced than others.
Available supplier; Local source of supply, rather than international/overseas.
Greater then 32 nodes per bus; Standard one unit load = 32 nodes per bus, but 128 and 256 node cable devices are available, often at greater cost, by increasing the receiver input impedance.
5V supply. There are a lot of 3.3 devices out there too, more than enough to make your head spin.
Failsafe; receiver output guaranteed high for receiver input shorted, open or all transmitters in high impedance state.
Fault tolerant and ESD protection.
Dual in Line Packaged: 8 and 14 pin available, but SOIC devices are probably the way to go if using printed circuit boards, as pins are at 0.05” rather than the DIP 0.10” pitch and make for a potentially smaller device.

Of the restricted list of suppliers researched; Analog Devices, Maxim and Linear Technology, the product profile of the latter seems better focussed on communications networking chip technology as a percentage of total business. This shows in the extensive RS485 product range (mind boggling) and the plethora of innovations adding operational performance improvements to the basic product. It certainly seems to make their lesser devices more capable and at a keener price point than those of the alternative manufacturers. 5V supply and DIP packaging notwithstanding.

I personally am unlikely to exceed the standard 32 node model, but have identified three LinearTM candidate devices that fit the bill, although I have no need for anything other than a 'standard offering'.
LTC1487CN8 256 nodes DIP8 $1.85 mfr unit price
LT1785ACN8 128 nodes DIP8 $2.80 mfr unit price
LT1791ACN 128 nodes DIP14 $3.05 mfr unit price

Depending where you got mileage and prices will vary, so shop around.
In the event my regular supplier Rapid, in the UK have the first device above as being a discontinued item and the LTC1487CS8 the SOIC alternative is currently £1.30 ex VAT, but is in supply only until stocks run out. The Maxim MAX3082CPA+ comes in at £2.49 ex VAT.

I am going to buy in ten LTC1487CS8 (Rapid 82-1142) to make the price break and will mount them upside down dead bug style until such time that I have circuit boards to use – not holding my breath at all on that eventuality.

The Sipex SP485CN (Rapid 82-0868) in a SOIC package at £0.69, ex VAT, would probably do just fine for my requirements.

However I have identified the requirement for a device to be failsafe so that your receivers aren't left floating, and perhaps taking hits in a very electrically noisy environment, and found a sufficiency of devices able to handle more than the standard 32 nodes. 3.3V devices SOIC devices are the future way forward of course. Carefully check the specs for the salient points before parting with your cash.

With the right devices, there is no biasing needed as the recievers failsafe to mark high, if wired up the right way round. Other than being able to make a link or two to make them half duplex, I can't really see any great advantage of full duplex chips as the transmitting chip will probably want to disable it's own receiver when it's transmitting anyway.

You can easily be spoiled for choice. :)

Still thinking and hoping that BH67 is making the most of his family time.
 

moninos

New Member
Think different

This is my first post. Please forgive my mistakes as i am french.
It seems to me that the real questions are not being asked.
What are you trying to accomplish?
-replacing a boring job with some equipment
-increasing the reliability of the monitoring système
-have fun tinkering and be a hero if it works.
What's in it for you, really ?
What is your position in respect to the ship crew?
I am asking because all the discussion above may be the partially right answer to the wrong question.
The question is not : how do I drive zillions of rainbow LED's but:
WHAT DO WE TRY TO ACCOMPLISH
As I see it, we just need to monitor a bunch of bearing temps and provide a clear blatant signal when something goes wrong.
And if I'm right (correct me) this event is rare (once a week, a month, a year??)
What is the probabilty for several bearings to fail at the same time?
Speed is not important. One reading per bearing every 10 sec is enough ?
However robustness and maximum reliability is a must !
Given all the above why on earth do we need all this failure prone mess of LED' or unreadable small confusing display? I don't want to visualy scan dozens of small LED' all the time, I just want to know if all is right.
So here is m'y suggestion:
One big green light indicates that all is OK . (99.9% of the time ?)
One big flashing red light means trouble.
In that case a large 2 digit Led display tell which bearing is at fault (overheat or faulty module)
The Picaxe in the contol room is the key to the system reliability.
Besides interrogating each node in a round robin manner, it will monitor every possible component of the system for instance:
- the current in the lamps (burnout or short)
- the power supply voltage
- the resistance of the câbles to the node
- its own proper functionning (watchdog)
So the big green light does not only mean that the bearings are OK but that the entire system works flawlessly.
This thing cannot fail and if it does, as it probable will over time, it must signal quickly its own failure.
Each node will have a low cost rugged thermistor a 08M2 will do the local work . When interrogated it will only indicate Ok, too high, too low. No need to send the temp. It is obvious that if an alarm is triggered a human will rush to the indicated bearing with his infrared gun to check it
There are a couple of led's on each node (temp in range, transmitting, etc.)
Serial Communication is done at the lowest rate using line buffers. Error checking and redondant transmitions are easily implemented because we have a lot processor time (32Mhz!).
Maybe there is a separate cable
for the 7.5 to 9volt power supply. Each node have its own 78L05 regulator.
And a shielded pair for the data (75meters is a long way).
To conclude: failsafe is the keyword here.
I hope this helps some.
 
Top