These may not be useful (yet) but they demonstrate some of the ideas. I hope this page will grow and others (I trust a few brave souls will try this software) may add some cool things to do.

Cool Thing 1

Try creating another UI. Just open another command window or change the UI startup script using exactly the same parameters EXCEPT change the node name (the -n parameter). So if you have c1 and c2 for the existing nodes try c3.

> erlink-gtkmain -n c3 -h LT-VAIO-100 -c ui -s switcher@LT-VAIO-100 -m sm

Ok, this is not 100% yet, start the two UI nodes but don't press power-on until both are up. If you then press the power-on button on one of the UI's both will spring into life. Everything you do in one is reflected in the other and they both work the radio. You could even have these on separate machines, one XP and one Linux even. Why does this work, simple, they both have the same class name of 'ui'. Any events the application receives will cause it to send updates to both UI's. 

I said that a UI must never update itself otherwise things like this will not work. I slightly break this rule at the moment and some things don't work. If you press a toggle button or select a band that state is not reflected because GTK+ itself updates the widget state and I forgot I need to also set that state myself (to be fixed).

Cool Thing 2

If you read through the operation page at the bottom there was a section showing how to set the RFE enable flag. This actually used a very very basic scripting engine. I think this will be really useful and a full implementation in Erlang, Python and Smalltalk may emerge one day. In the meantime there is a little more you can do with this and it's certainly an area where experimentation is easiest.

Start the scripter by registering it. It uses default class names at the moment, so if your application node does not have class 'sm' you will need to change the code. The return value from the register is the gateway for this client (see the techno section).

erl> Pid = scripter:register().

Try closing and restarting the UI node but don't press power-on. This command will power-on remotely.

erl> scripter:power(Pid).

Something just a touch more visual.  This will start a scan from the current frequency for 100KHz.

erl> scripter:scan(Pid, 0.1).

When done deregister.

erl> scripter:deregister().

REMEMBER: erlang variables are immutable. If you try and run this from the top again you will get an error on the first line because Pid is already assigned, use a different variable name.

Have a look at the code in scripter.erl, it's very straight forward. Here is the scan function.

Messages are sent to the gateway with a destination class of 'sm' which is the application node. The message is a FREQ event which takes a number representing a positive or negative frequency increment in MHz (in this case 100Hz). The long train of terms is because the state machine takes up to 10 parameters. This is ugly and will be addressed. Once the first message has been sent a new variable is used to count down to zero in 100Hz decrements. If the countdown is still positive then we sleep for 100ms and recurse (all iteration in erlang is done with recursion).  Clearly this is not a scanner but it doesn't take much imagination to see that it could be.