DTMF dead?

Earlier in the thread, you were talking about DTMF. Now you're all the way to SSL? What are you trying to accomplish?

And, if you've got a 2-wire system, I'd use AFSK before I used DTMF.

Good Luck! Rich

I'm (co) working on a system that is primarily based on ethernet / IP protocol. An antire system can consist of several thousand units (all kinds of devices) in total. Some of the units need to be really cheap and small to be economically viable.

For a particular type of unit there is a severe space constraint. So there is a trade-off to take ethernet all the way to the smallest units or place a master ethernetproprietary converter unit at a convenient location and feed the smaller units with a proprietary protocol.

Having to use SSL or not is just one of the trade-offs to choose between standard ethernet or going proprietary.

I was hoping DTMF could provide a cheap and easy to design way to get some communication going (thats where it comes down to in the end). But I couldn't find any cheap chips. Worse, surface mounted DTMF chips are even harder to find. That raised my question: Is DTMF dead? And I think the answer is yes.

Tim, stupid question: what is OOK? Do you have a link to a website? Since 'ook' is a commonly used word in Dutch, Google gives me no suitable answer.

Simply: On-Off Keying.

It is commonly used today for low-speed, low-reliability RF data links between lots of embedded doo-hickeys.

An example of it being used for communications between many remote nodes and a central master node along a single wire are the coded fire callboxes that used to be common in many european cities and even some (e.g. Washington DC) US cities. Trigger the callbox and it sends a coded on-off pattern to the central location indicating its node number.

Now your application might be higher bandwidth than these fire callboxes, but I can guarantee you given what you've described so far that your wires are shorter!

Tim.

Ah, thats something Google can deal with :-) It looks interesting indeed. I'll take it in consideration.

How about doing both! Implement a proprietary ethernet protocol. You can then re-use your ethernet network equipment and simplify cabling etc. The protocol can be as simple as insisting that your raw data packet fits in a single ethernet frame. Use MAC addresses directly as your node address and your embedded side doesn't even need a "proper" protocol stack. Something like Microchip's ENC28J60 is nice since it handles a lot of stuff for you.

The down side of this is that on the host side on the PC you need to either write a protocol driver for your proprietary protocol or write raw ethernet frames directly from your application -- both are not so trivial (at least not for me).

Nico, If you have any choice, go with a standard cable, like a four twisted pair ethernet type, and then use PoE for your power, and then two of the pairs for your communications. DO NOT USE DTMF unless you have a full head of hair, and don't like barbers, as you will pull it all out. If you have that many nodes trying to communication via DTMF, you will have no easy way of dealing with collisions, noise on the line from all the different termination points, etc. Go with a standard, like 422 or 485, and you can cook up your own protocol to get your data polled and comm'ed reliably. Also, you will quickly find, if you have that many nodes, that you do not want to send all the power from a single main source, but will need to break your network down into smaller groups that all power from relatively local supplies. Adding up even a low power node, say 4 mA, and you get 100 of them, with cable losses, and your start tracing your wire runs using an IR viewer!

And again, drop the DTMF. That is too slow a signaling method, and it really isn't that noise resistant in a multi-drop environment...

Charlie

The problem is that an ethernet modular jack plug won't fit. Besides I would like to use a very reliable and easy to mount connector like a small size spade.

That's true. That is why I decided the nodes should shut-up until called for. No collision detection is needed.

That is one of the reasons why I'm investigating communicating over the power supply lines. The less wires, the thicker each wire. Also, less wires means less connections which in turns means less errors and less problems.

BTW, as the outline of the project is maturing it turned out there are no going to be hundreds of units on one line but aprox 50 to 100 which makes lives a little easier.

Umm, yes and no.

Google "Jeremy Bentham" and "TCP/IP Lean". He got el-cheapo PICs talking to the internet, and wrote a book on how to do it.

I think it sprang from a project to have air quality sensors all over an urban area that could be read from the internet. Each PIC is a tiny webserver with a simple yet cunning page showing the data.

A very limited realization with many restrictions. The fully functional TCP/IP takes somewhat 256k RAM at the least; and it heavily relies on the dynamic memory allocation and other OS services.

Those toys are good enough to be demonstrated at the lab LAN conditions. It will be many of problems if you connect them to the real internet.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

Wow that is weird. I clearly remember using pc-xt with 386 kB ram, with a simple nic and did file sharing (client), ftp, email, talk, telnet, wais client, gopher client, and more. Today, people deliver web servers with sensors with under 32 kB ram, protected by a VPN tunnel with NAT.

Maybe you mean implementing both v4 and v6 with every possible protocol plus every support crypto service.

to

The IP packet can have a size of up to 64k. How would you handle it with 32k of RAM?

plus

The memory demanding part of TCP/IP is the packet fragmentation reassembly. Also, the performance optimized stack needs a lot of memory.

Vladimir Vassilevsky

That is handled by MTU at the link layer, and the packet size is adjusted. I can FTP 7 GB files that go through 10baseT with an MTU of 1400 bytes or so.

If the application only ever needs smaller packets ypou could just drop it.

Bye. Jasen

I've looked into that sort of stacks but I'm not very convinced these stacks are secure and really usefull. Yes, bit-banging an almost pre-defined ethernet packet is possible, but it offers very little flexibility for the device like being able to configure itself by DHCP or using SSL.

The data which is being handled in the project I'm working on requires some level of protection since the network is accessible by others. A real tiny device would take too much dedicated programming work resulting in too many bugs and leaks.

I'm using uIP -which already is a very small TCP/IP stack- in the bigger ethernet connected devices with a BSD style socket layer on top of it.

They're certainly useful. Secure? Probably not by "desktop PC" standards, but you have to keep in mind that (1) they're not very attractive targets for hacking (ooh, ah, you knocked an air quality monitoring station off the Internet! Impressive... not! -- no kudos with your cracking buddies) and (2) I wouldn't be surprised if the likelihood of damage from vandalism vis-a-vis a baseball bat is a lot more likely than damage from Internet hackers. :-)

What sort of data rates does each device require? Many small microcontrollers can do something like public key encyprtion at the "kilobytes per second" rate these days.

Ah, OK... if you already have the stack, using "regular" TCP/IP protocols certainly makes sense.

Interesting idea.

Book and CDROM, 2 editions, neither available from iosoft.co.uk direct, but "both available from Amazon.com", who list the book as out of print, "we don't know if we'll ever get more". Two on the "new and used" list for 136 pounds and 176 pounds. Mmmm ... I don't think so.

Anywhere to buy/read this creation without getting gouged? Or is this just old hat and not actually used any more?