next topic »

[on:]

I've been designing a monitoring and control network for some time now and have 9 node types defined but am looking for ideas for other types.

Node functions currently designed are

AMPS - ACS712 hall sensor for 0-20A
COUNT - high-speed (say < 1MHz) general-purpose counter
TEMP - general temp sensor
TCOUPLE - thermocouple temp sensor
DIGIN - 2 or 4 hardened digital inputs
RELAY - small latching relay
SSRELAY - small solid-state relay
SHUNT - high side current sensing across a shunt
VOLTS - 10-bit voltage reading, 0-30v

These are just generic functions that are useful and probably more than enough for a proof of concept, but can anyone think of others? I don't think anything too specific is called for now, a 24-bit ADC might be nice but a bit too specialised for the time being.

Have I missed something obvious?

All ideas welcome.

______
Rob

[Reply #1 on:]

Hi Rob,

You might wnat to have a look in the SNMP community as this protocol is used to monitor many different devices over the network. Historical meant for routers and switches but any device connected to the net can be monitored.

e.g. http://arduino.cc/forum/index.php/topic,50848.0.html

[Reply #2 on:]

Think almost ant physical unit can be in the list

RFID, HUMIDITY, LUX, FREQ (iso count?), etc

The difference you should make is about the datatype necessary and the meaning - syntax vs semantics -
Most physical units will be float but you can use longs when you use e.g. milliVolts iso Volts. The datatype long will be large enough to handle most cases and that it is faster than floats you allready know.

name   datatype   Units
AMPS   float       Amperes
FRQ     long     Herz
TEMP   long   milliCelsius
etc

You have SSRELAY in the list that means that besides sensors you also monitor actuators. Should SERVO (angle) or MOTOR (rpm)  also be in the list ?

sofar my 2 cents,
Rob

[Reply #3 on:]

Thanks for your input Rob.

I actually have about 30 "point types" defined, the 9 I mentioned are for an evaluation PCB I will make as a proof of concept. However you mentioned a few there I hadn't thought of (LUX, MOTOR and RFID).

I do not allow floating point at the node level because they are very small processors (Tiny84/85s) so of course I don't want to load the FP library. However every point can define a divisor and a 0 offset, plus there are display options to place a decimal point etc. This is all stored on the controller so information can (I hope) be displayed in any format.

One thing I had done though is limit the value a node can report to 16 bits to reduce the packet size. This is more than enough for the sort of thing I do (solar battery level for example) but maybe not for other applications.

I do have some spare flags I can use to indicate 32-bit data in a frame, but maybe I should just up the default data size, doing this increases the packet size but improves orthogonality, I hate having "modes" where you treat things differently according to some other condition.

Anyway thanks for causing me to revisit this, it's hard designing something like this in a vacuum without any form of peer review.

______
Rob
 

[Reply #4 on:]

One thing I had done though is limit the value a node can report to 16 bits to reduce the packet size. This is more than enough for the sort of thing I do (solar battery level for example) but maybe not for other applications.

IIRC in SNMP a 64 bit counter is the largest unit. Maybe you should define also have a "string" format - [size]

• [1] ..... [size-1]   where [ ] is one byte.  Note RFID's can generate quite a long identification string (easily 10 or more digits), these might be packed per two digits in one byte (BCD-alike). BARcode readers and especially QRcode readers will produce dozens of bytes.

restriction of packetsize to 16 bits is often marginal as overhead to get the 2 bytes often uses many more bytes. E.g. looking at I2C you need 4 or five bytes to request 2bytes data. UDP over ethernet is even worse. Only in a point to point connection this kind of reduction makes sense imho.

If you have more questions just let me know, I mark the notify  (or PM )

Rob

[Reply #5 on:]

Sorry I haven't explained the protocol very well.

I've been working on other projects for 6 months and have got a bit rusty on my spec so I'm just going back to it to make some improvements and changes. As it happens I think I have it (ie 32-bit) covered.

The packet format is as follows

Code:

SYNC--ADDR--FLAGS/SEQ--CODE--LEN--[DATA]--CRC

where

SYNC – The value 40 which is used to interrupt receiving processor then allow it to synchronise timers with the transmission’s bit time.
ADDR – The physical address of the receiving Node, or one of the system logical addresses.
FLGS – Expansion Flags, not used at present but will be useful for things not implemented yet such as sending Point’s security level.
SEQ – The frame sequence number comprises the lower 4 bits of the third byte.
CODE – This field holds the command code the Node's application should action.
LEN – The number of bytes in the following DATA.
DATA – Optional data, up to 255 bytes as per the preceding LEN field.
CRC – An 8-bit CRC.

So as you see I can accommodate data up to 255 data bytes in a packet, it's the format of the data that is in question.

Within DATA are PDUs (Point Data Units) and a PDU has the following format

ADDR - The address this data comes from.
POINT - The Point this data comes from.
CNTRL - A control byte indicating the format and length of the data in this PDU.
TS - a 4-byte timestamp.
DATA - Point’s data; length and format according to the CNTRL field.

What I hadn't done was provide for CNTRL to have an explicit option for 32-bit data, currently defined options are

01 – 2‐byte raw value.
02 – 3‐byte standardized value.
03 – n‐byte ASCII formatted data.
04 – n‐byte binary data.

So I'm almost there, in fact the current format allows for up to 31 data bytes in a PDU so I think I have it covered with option #4. Other options possibly should be a bit field for binary in/outputs.

PDU's are designed to be stand-alone data units that may start at a light switch but could end up in a data base or an Excel spreadsheet, thus some of the information is redundant at the frame level.


______
Rob

[Reply #6 on:]

OK, what network will be used or is it open?

[Reply #7 on:]

Nothing you've heard of, just something I've been tinkering with for a while. It's an RS-485 Async network I thought I'd do because

a) I want something for monitoring and control around my motorhome, and
b) I enjoy working with comms stuff.

______
Rob

[Reply #8 on:]

All ideas welcome.

Hi Rob,

For ideas of different sensors, there's lots of them over at Seeed Studio:
   http://www.seeedstudio.com/depot/sensors-c-144.html

On a more general note...

Are these your IO Nodules, as described on your web site?
So they will have an I2C interface?

I happened to stumble upon your web site yesterday, and this ION idea is very cool.
Basically a digital sensor, something I've been thinking about for a while.

Here are some other ideas I have:

  - make the electrical interface more generic, supporting:
         a) basic sensors, like above (polling using I2C) (good for bus network layout)
         b) interrupt ability, avoids polling, sometimes helpful
         c) full two way communication (using SPI) (good for point-to-point network layout)
    the idea is to have the interface support simple devices (sensors)
    and also complication devices (other processors, with a fast, 2-way interface)

 - define the physical specs of the nodule, so there is a physical "plug-n-play"

 - software library is designed such that talking to a rotary encoder (for example),
   via a nodule is no different from talking to an encoder locally connected to a processor
   (allows someone to prototype using these digital sensors, then move to using
    the same types of sensors connected directly to the main processor (for production, to lower cost),
    without having to re-write their code, just need to modify the configuration)

- have a generic way to define the messages passed between nodule and main processor
  (See http://en.wikipedia.org/wiki/Remote_procedure_call).
  Makes for a powerful system:
      - can support multiple languages to talk to the nodules using code generation techniques
        (C, C++, Perl, Python, VB.net, Javascript, etc...)
      - can query nodule about it's capabilities and then build an interface dynamically at run time
        (imagine: web page that automatically updates, showing all nodules plugged in, and their current status)
      - code to control and monitor, say a GPS unit from company X, is exactly the same as a GPS unit from company Y,
        assuming they follow the same interface

Ok, there's enough ideas for now. :-)

I'm just throwing these out there... kinda brainstorming.

Microcontrollers have gotten so cheap ($0.50) that, to me, it makes
sense to make all these dumb devices a lot smarter, especially for
prototyping or one-off projects.

cheers, John

[Reply #9 on:]

Are these your IO Nodules, as described on your web site?

Yep, although the information on the site is under review as I've made a lot of changes lately.

So they will have an I2C interface?

The network itself is async and chips can interface directly with that IF they have room for the protocol (which I intend to be OS once written). However not all chips have the power or space to implement the protocol (say a Picaxe), so I plan to have chips that interface using async to the network and I2C to an "application processor". That's where the I2C comes from.

Basically a digital sensor, something I've been thinking about for a while.

Yes I've seen all the bricks, jeenodes, etc but AFAIK they are not designed for noisy real-world environments and long distances, and they all still need you to know about the hardware, for example you have to know how to drive a current-sensing chip. My idea is to have a generic interface, you ask a "Point" for it's value and you get a number. How that number was arrived at is immaterial and figured out by the Node designer. You can in fact have "virtual Points" that are just the result of a calculation.

This of course adds complexity because each Node needs a processor and line driver, but as you say these are very cheap now.

Another advantage of this is that measurements are done at the coal face, a 24-bit ADC can be 300 metres away and there are no analogue issues.

interrupt ability

I actually just removed that feature from the spec, I'm open to putting it back in but it did add complexity.

define the physical specs of the nodule, so there is a physical "plug-n-play"

Done, in theory a simple network needs no programming.

can query nodule about it's capabilities and then build an interface dynamically at run time

Done. Nodes are allocated address when first added to a network. They then report the number and type of Points they implement and how their data should be displayed. This then is plug-n-play as the Node holds all necessary information for it to function on the network.

code to control and monitor, say a GPS unit from company X, is exactly the same as a GPS unit from company Y, assuming they follow the same interface

Exactly, in this case the Node would report that it has a Point of type GPS and the format of its data is predefined. The Node's data can in fact be "published" if the appropriate logical address has been defined.

can support multiple languages to talk to the nodules using code generation techniques
        (C, C++, Perl, Python, VB.net, Javascript, etc...)

The controller and/or a gateway Node can be used to talk USB to a PC. A protocol and command set will do be developed but any langauge can be used for a PC application.
   

I'm just throwing these out there... kinda brainstorming.

Good to hear it and thanks. I'm in the process of designing an evaluation board with about 10 Nodes, a protocol analyser, network PSU and a master controller. They will all be connected on the PCB for easy debugging but also be able to be snapped off so the various bits can be used over wires.  

I don't think I've handled all the things you mentioned but it seems that my spec is pretty close.

_____
Rob

[Reply #10 on:]

I'm just throwing these out there... kinda brainstorming.

Good to hear it and thanks. I'm in the process of designing an evaluation board with about 10 Nodes, a protocol analyser, network PSU and a master controller. They will all be connected on the PCB for easy debugging but also be able to be snapped off so the various bits can be used over wires.  

Sounds great!  I think you're doing some innovative things.

I'm new to this board, but I'll keep an eye out here and at your website for any of your updates.

John

[Reply #11 on:]

Hi John,

I sent you a PM about a new forum I'm running for this network.

______
Rob

[Reply #12 on:]

I sent you a PM about a new forum I'm running for this network.

Got it.  Thanks ... checking it out right now.  -j