Project notes
Aims
One or more of:
- Product that very simple and makes money - like ipod.
- Product that makes money.
- Be something we can say we have been working on.
- Provide experience in new areas.
- Continued programming practice.
- Do something really useful.
Techniques
Software:
- Real-time - unpredictable events
- Embedded
- Communications
- Sockets
Hardware:
- Sensors
- Control
- GPRS
- Embedded
- GPS
- RFID
Strategies to generate ideas/move on to further stages
- A: Use software feature requirements (e.g. real-time)
- B: Use hardware research
- C: Think what young people like (something simple without
much research)
- D: Think of modbus-related products
- E: Follow through on existing ideas
- F: Look at what hardware/techniques/research may be in
common between different ideas.
Ideas
Strategies
A- Software features requirements :
- Program with real-time features/sockets:
- small time period relative to resources
- different priorities
- Areas for real-time scenario:
- SKILLED ACTIVITIES
- SKILL-SUFFICIENT RESOURCES:
sitting,walking,driving,typing.
- UNSKILLED-INSUFFICIENT RESOURCES for SOME humans:
- disability, toddler (sitting up, walking)
- UNSKILLED/PARTIAL -INSUFFICIENT RESOURCES for ANY AND
ALL humans
- (things happening sometimes too fast &
unpredictably):
- emergency room / dealing with things going wrong
- keeping hold of ball in hockey/football, scoring.
Avoiding hits in boxing (other people most unpreditable)
- weather changes (e.g. in boat)
- current ideas:
Writing our own server
Writing a TCP (or UDP?!) server seems like a good project for providing
further experience with sockets, multi-threading, protocol-handling and
maybe real-time. However, many services could be more easily
implemented by using a servlet or CGI in a web server (e.g. Tomcat or
Apache) - this would also, in some cases, allow the use of a browser as
a ready-made client. Using a servlet or CGI would probably not provide
similar experience of sockets etc. So we need to think of a project for
which the use of a web server would be inappropriate.
Reasons for not using a web server:
- The HTTP protocol may be inappropriate because:
- The application requires a different (standard) protocol. E.g. a DNS server has to use the DNS protocol.
- The overhead of HTTP (headers
and URL) makes messages too long. The overhead is typically tens (or
even hundreds) of bytes on both the request and response messages. This
could be a problem if a high throughput is required.
- The application requires a non-stateless protocol (HTTP
is stateless) - e.g. to keep down the size of messages, or to provide
transactions (where a sequence of operations need to done atomically).
State can be implemented using cookies or request-parameters - but this makes the request
messages even longer!
- There is a real-time requirement. E.g. multimedia streaming.
- The web server may be too "heavyweight":
- The web server requires too many resources (e.g memory). E.g.
if we want to write in Java, we would need probably need Tomcat (or
Apache plus Tomcat) - which requires hundreds of megabytes of RAM. This
could particularly be a problem in an embedded environment. However,
there are lighter-weight servlet containers (e.g. Winstone).
- The web server may be too slow in responding to requests -
i.e. there is a real-time element to the service. A response time of
100mS may be perfectly acceptable for delivering a web page to a human,
but may not be acceptable for other applications (even if there is no
hard real-time requirement).
Note that the client doesn't really enter into the reasons for not
using a web server. A web server can be used with clients other than a
web browser, and there is no reason why a web client couldn't be, for
example, a non-interactive process that does its job in the background.
One possibility is a generic server.
Ideas
AA: Ping tonometer
- hardware req
- to bounce sonar wave off eye
- sonar transmitter (speaker)
- impulse (frequency range of eye)
- to receive bounced wave and be able to detect
small changes
- sonar receiver (microphone)
- to store/transmit IOP changes
- software req
- signal-to-noise processing
- filter out eye-movement (e.g. saccadic) vibrations
- storage/transmission of iop changes
- research
- anything similar available or under development [DONE]
- available libraries for acoustic signal processing [see below]
- effect of saccadic eye movement on pressure
- possibility of passive system - maybe using saccadic
movements to provide pings
- pros/cons of combined/separate transmitter/receiver
AB: Night-sky guide
- hardware req
- software
- library of star maps
- calendar
- research
- available library of star maps
AC: Directional sound alerter
(e.g birds - has to be selective)
- hardware req
- to pick up high frequency sound (birds)
- software req
- signal-to-noise processing
- location of sound
- mapping of sound to bird
- research
- directional microphones (phased-array?)
- available libraries for acoustic signal processing [see below]
AD: Bird song recognizer.
- software req
- pattern recognition of sound to bird
- library of bird songs, calls
- research
- available library of birdsongs and calls
- available libraries for acoustic signal processing [see below]
AE: Sound-guided camera
(e.g. in garden)
- hardware req
- to pick up sounds
- to control movement of visual equipment
- pan&tilt&zoom motor, linear induction
motor
- to record visual events
- to transmit data remotely and wirelessly
- battery or power supply. camera+motor+wifi may need 10W -
a lot for a battery.
- weather resistant; monochrome or colour & switch to
monochrome at night; camera with motion detector/video
actuator; resolution 330-400 pixels (depending on costs).
- software req
- signal-to-noise processing
- location of sound
- research
- available systems e.g. in security
- split between embedded and remote processing - e.g.
effect on bandwidth requirement
- available libraries for acoustic signal processing [see below]
AF: Dead-reckoner.
- hardware req
- gps receiver
- distance-ometer (accelerometer?)
- compass?
- software req
- calculation of lat/long from last gps location with
distance
- research
- anything similar already available
- available accelerometers
- accuracy of dead-reckoning using available accelerometers
AG: Personal energy conversion.
- Think: activities that might do and need to convert
- run-on-spot, exercise- machines, bike, rowing etc
- outdoors
- hardware req
- to nick energy - pressure sensor, drive wheel ..
- convert energy - transducer
- store energy (battery, mains)
AH: Protocol converter.
AI: Multiple-sonar obstacle detector
for robotics and blind.
- hardware req
- multiple sonar transmitters and receivers
- software req
- locate things to avoid in path trajectory
- object, fluid
- distance,height,movement-trajectory/speed.
- research
- existing devices e.g. in robotics
AJ:
PDA for cycling/camping
- rechargable (solar/bike), reference for
bike/plant ID/first aid/etc., sonar for night movement detection,
robust, GPS,GPRS.
AK: Modbus-related products.
- AK1:
AutomatedTester
- software req
- execute battery of tests to test slave
- each test is Modbus command + data, with expected result
- research
- software req:
- 1 or more serial
interfaces
(/dev/..)
<--
BRIDGE ---> many tcp masters (X devices on
each
interface)
- AK3: ROUTER:
- software req
- 1 or more serial (/dev) &
TCP interfaces
<--|
ROUTER ---> many tcp
masters ( X devices on each interface)
- 1 or more tcp interfaces: on each interface 1 or
more
ports: on each port 1 or more slave IDs
- Remote configuration of slaves (addresses, ports,
interfaces) via extended modbus protocol. with local GUI.
- hardware req
- compatible with embedded device
- research
- what already available and how can improve
- maybe inclusion of SNMP converter (see AK4)
- use of router as a proxy server
- encryption
- would it be useful
- how to do it - SSL?
- AK4:
Modbus-to-SNMP Converter
- software req
- SNMP server ("agent") that converts SNMP requests to
Modbus slave requests
- map SNMP names to Modbus slave registers
- support report-by-exception, i.e. alarms ("TRAP")
- provide access control and security?
- research
- whether a need by a network manager who monitors both
industrial and non-industrial devices
- what already available [DONE]
- Java support for SNMP [YES - SNMP4J]
- does SNMP include any provisions for security? [YES -
in version 3]
- is there a free general-purpose SNMP client ("manager")
that we can use for testing? [YES - Net-SNMP]
- AK5: Register
Mapper
- big value and endian and address mapping conversion
- research
- master software to see if the above features are still
not configurable in master software and so still a problem
- AK6: Slave
interrogator
- software req
- probe slave with various comands and addresses to
determine (where possible):
- register addresses used
- commands supported
- big-value variant used
- serial settings (baud rate, stop bits, parity)
- whether RTU or ASCII
- slave ID (may be multiple, e.g. Solartron flow
computer or when using RS485)
- whether address spaces overlaid
- research
- already available? [DONE - can't find anything]
- what could be determined from probes
- AK8: Other
products
- research
- check emails for requested products/features [DONE -
nothing new]
- look at modbus.org for new developments
- look at modbus forums for product/feature requests
[DONE - nothing of interest]
- look at competitors' offerings
- look at Common
Industrial Protocol and its relationship
to Modbus. [DONE - CIP looks too huge to get involved with,
and probably too expensive - I suspect you have to pay license fees! ]
AL: Generic TCP/IP server
- software req
- 3 possible variants:
- skeletal server with "hooks" (plugin APIs) for request parsing, request handling, and response generation
- server for general purpose protocol (with GET, PUT, etc. requests), with hooks for request handling
- generic server with configuration file for protocol and hooks for request handling
- lightweight - suitable for
embedded/high-throughput/fast-response applications (i.e. applications
for which web server would be inappropriate)
- research
- what non-trivial (but general-purpose) features could we provide?
- what requests (in addition to GET & PUT) are typically used in protocols
Research
AA: Ping tonometer
Speed of sound is approx 340m/s in air and about 1500m/s in water (see Wikipedia). An eyeball is approximately 30mm diameter. If the eyeball acts as a cavity resonator,
we would expect the diameter to be half the wavelength of the
resonance. If the speed of sound in the humour of the eye is around
1500m/s, then a half-wavelength of 30mm would correspond to a resonant
frequency of 1500*1000/30 = 50kHz. The resonance we are interested in
is probably not what is normally called a "cavity resonance", and is
probably determined more by the elasticity/density of the sclera
and the pressure of the humour (haven't yet found a reference for this
kind of resonance). I would expect the frequency of this resonance to
be much lower than 50kHz - though I can't justify this.
Have yet to find any good information on eyeball resonances. One source
reckons that "there is an eyeball resonance in the 60-90 Hz range". A patent
application says that "resonant frequencies of a pig's eye
located outside of the head were
found to be between 100 Hz and 1 kHz, higher frequencies being
attenuated because of the viscous nature of the aqueous humor and the
vitreous body", but says for the human eye that "the lowest vibrational
mode is predicted to be at about 1 kHz".
The pulse used to "ping" the eyeball probably has to cover a range of
frequencies that includes the resonant frequency (or frequencies) of
interest.
"Acoustic resonance analysis" has been used for inspection
of mechanical parts for defects, checking
chicken eggs for embryo viability, and checking
peaches for ripeness.
There are several patents (or patent applications?) for tonometers
using acoustic resonance:
AC: Directional sound alerter
Information on getting direction of sound source using microphone arrays:
- Microphone
Array Support in Windows Vista - yes, MS seem to have
provided support in Vista for detecting the direction of a person
speaking and using signal processing to "point" an array of microphones
at the person.
- Ultra-Directional
Microphones - very mathematical article. Gets directionality
simply by delaying signal from each microphone by appropriate amount
and summing results. Points out that directionality depends on
frequency and microphone spacing - difficult to get single microphone
spacing to cover wide range of frequencies.
- Voice
Tracker Array Microphone - an actual product for use with a
PC, which locates and tracks person speaking. Costs about $250.
- Wearable
Phased Arrays for Sound Localization and Enhancement -
investigation of using microphones distributed over the human body. Use
correlation to determine arrival-time differences, and learning techniques to map
arrival-time differences to direction (since body moves, the spacing between the
microphones is not fixed). Article contains maths, but also lot of
readable practical stuff.
- Acoustic
source localization, Microphone
array, time-difference-of-arrival
- short Wikipedia articles on the subject. The first says that
cross-correlation is central to determining the arrival-time
differences between microphone. The last article deals with the
geometrical problem of localizing the sound source given the microphone
positions and the arrival-time differences.
- Microphone Array Processing - there is apparently a group at the University of Surrey doing research on sound source localization.
AE: Sound-guided camera
Some available cameras:
- D-Link
Wireless 10x Optical Zoom Internet Camera - DCS-6620G The
DCS-6620G is a Wireless 10x Optical Zoom Internet Camera
with built-in microphone, low-light sensitivity feature, and 128-bit
WEP security capabilities.
- Artane
Online: IP Security Wireless
Motorized Camera
- Logitech QuickCam Sphere - PC, USB,
Microphone, Digital Zoom, Intelligent Face-Tracking features
motorized pan
and tilt for intelligent face tracking, plus a true 1.3 megapixel image
sensor for high quality pictures and video-even in low-light
situations.
- D-Link Internet Cameras
- Rimax IP CAM 7200 - Misco.co.uk
- IP Cameras - Panasonic, Mobotix, Axis,
Level 1
AH: Protocol
converter
- Protocol requirements
- protocol version
- location: address/port/id.
- Message:
- End - by character or length.
- Order - within message (byte order)
- Message types: cmds (cd,append (ftp) get 'file'
(http,ftp)
- Message format: ascii,binary, endian,
byte,16-bit ..
- Data (in message):
- Error:
- format
- sequencing
- CRC check
- action-for-errorcondition
- Order: sequencing:
- interactions (e.g. 3-way response)
- one way order (one-end only)
- Cryptography
AK3: Router
- What already available & how can improve:
- From quick research on Modbus routers, seems to be not many
routers, and what there is seems to be a bit of an after-thought.
- More of a problem is what is motivation for a router, since
master can send directly to IP.
- Possible use of a router is in security, using ACLs to
restrict access - see http://modbusfw.sourceforge.net/
but these are already standard utilities in linux kermel and probably
other OS. - From
quick look proxy servers offer caching, security, general control over
access to servers behind them - probably not that applicable
to a
modbus application.
AK4:
Modbus-to-SNMP Converter
Whether needed:
- The availability of converter devices (see below) suggests
that there may be a need.
- The security features in SNMP v3 enable Modbus data to be
made
available securely and with access-control. The lack of security in
Modbus is a recognized problem [references to be provided].
Useful links:
Some jargon (from a quick first scan of documentation - probably
wrong/misleading):
- "Object": either a simple variable ("scalar"), or a list of
objects. Scalar objects can have numeric values (of various types) or
string values.
- "OID": Object Identifier - hierarchical name for an object.
Form
used in messages is sequence of numbers (like IP addresses). Also
alphabetical form (like host names).
- "MIB": "Management Information Base" - essentially the
configuration of the hierarchical names for objects and the object
types.
- "Agent": SNMP server - receives requests to get/set object
values - i.e. the part that we would implement.
- "Managed device": normally the device that the agent runs
on. In
our case, the Modbus slaves would probably be regarded
collectively as the "managed device".
- "Network-management system", or "SNMP manager": SNMP
client, with user-interface.
Java support:
- Sun don't provide SNMP support, so far as I can tell,
except for an SNMP
agent (part of JMX) that provides information about the JVM
itself.
- SNMP4J
- "is an enterprise
class free open source and state-of-the-art SNMP implementation for
J2SE 1.4 or later". Supports v3 security, amongst many other things.
- Java
SNMP Package - another open-source package, but only v1 and
v2 support.
- Westhawk's
Java SNMP Stack - open-source "lightweight" implementation.
v3 support. No support for loading MIB, so may not be good for a
"generic" agent.
SNMP-Modbus converters already available:
AK5:
Register mapper
- A recent
thread on the Modbus forum was enquiring about such a device.
A couple of replies suggested devices that would do register address
mapping.
- Another thread
refers to "data concentrators", which can map registers from multiple
slaves.
AK6:
Slave interrogator
AK7:
Enhancements of current products
Possibilities gathered from previous notes and enquiry emails:
- Ability to save/restore registers in CSV format.
- ModSlaveSim/ModMultiSim: random values.
- Support for UDP sockets. This will provide Modbus/UDP
(with "TCP" packet) and "UDP
Encapsulated Modbus" (with RTU or ASCII packet). [DONE in Modsak/ModMaster]
- Option to display/enter unsigned register values. [DONE in Modsak/ModMaster]
- Support for string register values.
- Scaling/offset of displayed register values.
- Ability to select which columns of register-table are
displayed. Right-click on row displays dialog to display/edit all
columns, including hidden ones.
- Document that "TCP Encapsulated
Modbus"
is supported (i.e. use of RTU or ASCII packets over
socket). [DONE on web pages and Modsak/ModMaster user
documentation. Needs adding to ModSlaveSim/ModMultiSim user
documentation]
- Modsak/ModMaster: Add "custom command" dialog to send
arbitrary byte sequence to slave as command. Useful for testing slave
handling of errors, and for proprietary Modbus commands. Needs option
for adding CRC or not.
- Switch to different obfuscator - free version of
retroguard is no longer supported. ProGuard
looks best. [DONE for Modsak/ModMaster]
- Registration:
- Installation on Windows XP and Vista should allow
multiple non-concurrent users.
- Don't randomly vary product IDs - it confuses users. [DONE]
- Diagnostics (function 8):
- Count and report CRC errors.
- Sub-function 1 should close and re-open comms port (bug
fix).
- Support sub-function 3 (change ASCII
delimiter).
- Allow configuration of contents of diagnostics register.
- Support function 43 sub-function 14 - Read Device
Identification (recommended for use with CIP).
- Display state of serial control lines (RTS, CTS, DTR, etc.)
- Modsak/ModMaster: report response time of slave. [DONE]
AL: Generic TCP/IP server
- Possible non-trivial (but general-purpose) features:
- thread pooling
- secure socket (TLS/SSL) support
- "chunked" response as in HTTP
Signal-processing software
Some open-source signal-processing libraries and applications:
- MARF, The Modular Audio Recognition Framework
- "open-source research platform and a collection of
voice/sound/speech/text and natural language processing (NLP)
algorithms written in Java and arranged into a modular and extensible framework facilitating addition of new algorithms". There is an extensive manual (unfortunately it's a 223 page PDF file, which is difficult to navigate around), and Javadoc
for the API. It's primarily intended as a training/recognition setup (so
might be fairly directly usable for bird recognition), but has a lot of
methods that could be used in other ways (FFT, correlation, etc.).
Appears to be designed to work with sound input from files only, and
with whole of input read into memory - i.e. no real-time (streaming)
capability. BSD license - so I can think we can use it without
open-sourcing our own code.
- SPro -
"speech signal processing toolkit which provides runtime commands
implementing standard feature extraction algorithms for speech related
applications and a C library to implement new algorithms and to use SPro files within your own programs". There is extensive documentation
(thankfully in HTML). Input is handled as a stream, so potentially
could handle real-time input. Code hasn't been modified since 2003 -
this could be good (code is absolutely stable) or bad (code is
unmaintained)! License is GPL (not LGPL) so we couldn't directly use it without
open-sourcing our own code. However, the code isn't huge - we could
probably write a Java version without too much effort.
- Scilab - "open source platform for numerical computation" - similar to the commercial MATLAB. Huge system, which includes many signal-processing functions. Has its own interpreted language, but the actual numerical functions are implemented in C and Fortran and appear to be independently usable from C.
Like MARF, the functions are not designed for streamed data. License
appears to disallow commercial use. Might be useful for interactively
trying out signal-processing operations.
- baudline -
"time-frequency browser designed for scientific visualization of the
spectral domain". Old-fashioned looking program (Motif GUI), but easy
way to get spectrograms from audio files or microphone input. Note that
"microphone input" means it is doing real-time (streamed) processing.
- WaveSurfer - "tool for sound visualization and manipulation". Similar to baudline.
- The GNU scientific library has lots of numerical functions (including FFT, but not correlation).
- If we have to write our signal-processing code, the book Numerical Recipes
(third edition) is a standard reference for numerical computation
(including FFT, correlation, etc.) - although not everyone likes it
(see Wikipedia article). The second edition is available free online here. However, the code supplied with this book is restrictively licensed, so we shouldn't directly use it!