Wednesday, August 19, 2015

Vault-OS : Global Control Protocol Over ASN.1

I applied some of what I learned at work today to some source code I had at home and successfully compiled the entire, unique communications and command protocol for VOS from the open source ASN.1 compiler. It is still in flux so chances are stuff will be added to it eventually. Theoretically this binary will support VOIP, streaming video and many other kinds of devices running daemons. The protocol is a very generic digital control and command set that provides a similar functional environment to BACNet. I think station-to-station telephony is an important part of VOS and provision for this capability should be in there. You should be able to instantly mount a headset and talk over VOS to another workstation with a central directory. This is a ways off but the possibility will be there in the messaging protocol.

My time is limited lately, very long commute - but I was able to send and receive messages over web sockets in this format. I think I have the holy grail for supporting different protocols for the daemons from CAN to RS-485 all the way around. I also cracked the functionality barrier to couple to Lua scripts from ASN.1 with JSON syntax. There is a very simple way to control the parallel port under Win NT/2000/XP for a daemon using this method.

I have this crazy idea for daemons to support calls over Websockets to the server as a very easy alternative for extremely small devices. I'm talking thimble sized devices talking over WebSockets to the main server all-in-one. Devices like BASIC Stamps that don't even have room for TCP-IP stacks but can write a small stream of bytes as a protocol over Websockets and parse the response. Where would this come in handy? I am envisioning little systems monitoring keypads at entryways, tiny devices designed to control pumps and water/fuel metrics, maybe a small VT-100 terminal with a limited command set inside a staging area. A lot of these devices could not run BACNet over IP but they could run my little subset which is very generic.

At my current job there is no requirement for a graphical UI for the server monitoring itself on the host machine but this is a great way to supply that feature and keep it totally decoupled from the server itself which can operate even without a display device if desired.

I think running on Windows NT with numerous daemons this server will rarely consume more than 4 megs total RAM and should launch nearly instantly as a service if needed.


Sam said...

You talking about using Lua scripts to couple to small devices triggered a memory of something I found. This may be helpful. I read about this a long time ago and it interested me. It's written by John Walker, founder of Autodesk, Inc. and co-author of AutoCAD. Certainly not a lightweight. He wrote this little FORTH dialect solely to tie together programs and make them extensible with very low overhead. Maybe it won't help you in this case but it might come in handy some time. It should work with that neat GTK-server you found. I've always liked the simplicity of FORTH. I like HP calculators and FORTH is Reverse Polish Notation. Also just like assembly where you push things on a stack. Anyways here's a description link and manual.

His front page is also interesting. I can't remember where I saw it, maybe this site, but I believe he once used the torsion of fishing line tied to a heavy weight to measure the gravitational pull of nearby mountains.

Russell (106) said...

"Vault-OS: Yesterday's Technology Tomorrow!"

"Devices like BASIC Stamps that don't even have room for TCP-IP stacks but can write a small stream of bytes as a protocol over Websockets and parse the response."

Low power, low maintenance is the way to go for the smaller monitors.

Power isn't going be cheap and plentiful, so anything that places a low demand on your power, yet is still useful, is a boon.

KW Jackson said...

I've been curious for ages and now just have to ask. What are your electrical power solutions for long-term vault habitation?