Month: September 2010

Categories
Tools

Systems analysis

Dedicated design engineering tools are often oriented towards simple usage scenarios for one design aspect at a time. Complete systems in realistic scenarios are more costly and difficult to analyse due to multiple licensing fees and few working examples. The result is sub-optimal systems with poor performance. Quflow is currently integrating a multi-discipline and multi-scenario systems analysis framework using the following free open source tools:

Of these packages, pyvisa, spiro, traits, quantities and sympy are integrated and playing well together already.

Comments, requests for early releases and collaborations are welcome!

Categories
Examples Research

Receiving satellite signals

Watson et al. (http://plan.geomatics.ucalgary.ca/papers/watson%20et%20al_ion%20navigation_winter06.pdf) analyzed what matters most when receiving GPS signals in-door. The GPS system was not designed for this but with good antennas, modern receivers and long integration times it is possible. Their graph below shows signal strengths from different satellites plotted on a hemisphere circle. The result indicates that reflections within the building are not picked up – only the attenuated “line-of-sight” direction reaches the antenna. Another interesting conclusion from their study is that besides an antenna that picks up signals from the horizon well, it is only the quality of the clock signal that matters (assuming the receive chain is a typically good one of course).

Fig. 13–Mean Tube Fades vs. Building Geometry
Fig. 3–Tube Antenna Location

The Sony Ericsson Equinox phone (http://www.sonyericsson.com/cws/support/phones/topic/locationservices/equinox?cc=us&lc=en) is a good example that integrated antenna and clocking well. It obtained the best ever GPS availability when operators tested it in field, and was implemented according to new A-GPS integration guidelines (authored by Joakim Pettersson, founder of Quflow) that in detail explains how to stabilize antenna and clocking also in very small mechanics.

Sony Ericsson Equinox
Categories
Training

Interactive simulations

Quflow has experience with system simulation and system identification for aspects that has mattered in radio and power design for vehicles and mobile devices: user perception, power consumption scenarios, link budgets with fading, thermal design, waveguides, signal integrity, noise, water cycles etc etc. Most of these use quickly crafted models for specific needs. Here are links to sites which cover similar topics interactively online:

User guides for building your own interactive simulations can be found here:

Categories
Tools

Less is more

Quflow example: Working inside a subsystem as if it was the complete system:
[python]
>>> from quflow import Attributes
>>> obj = Attributes(x = 1)
>>> with obj:
… y = x + 1
… del x
…
>>> obj
Attributes(y = 2)
[/python]
Same example without quflow requires cluttering with symbols that hides the intention and does not provide any focus area to the logic:
[python]
>>> obj = dict(x=1)
>>> obj[‘y’] = obj[‘x’] + 1
>>> del obj[‘x’]
>>> obj
{‘y’: 2}
[/python]

Categories
Tools

System integration

Quflow example: Assembling and dynamically changing components of a system.
[python]
>>> from quflow import Scope
>>> s0 = Scope(x=1)
>>> s1, s2 = s0(y=10), s0(y=100)
>>> with s2: z = x + y + s1.y
…
>>> s3 = s2(s1) # s1 hides s2 in s3
>>> with s3: print x, y, z
…
1 10 111
>>> # above came from s0.x, s1.y and s2.z
>>> del s0.x, s1.y
>>> x = 0
>>> with s3: print x, y, z
…
0 100 111
>>> # above came from x, s2.y and s2.z
[/python]

Categories
Tools

Working with device drivers

Quflow example: Using a phone modem by defining a simple driver on-the-fly.
[python]
>>> from quflow import enter, exit, Driver, ports, sleep
>>> class Phone(Driver):
… commands = dict(attention = “AT”, call = “ATD%s”, hangup = “H0”)
… events = dict(ok = “OK”)
… procedures = dict(enter = “attention(), ok()”)
… expectEcho = True
…
>>> phonePort = ports()[2] # Assuming the third port controls the phone.
>>> phone = Phone(phonePort, timeout = 25)
>>> me = “+123456789” # My phone number – a global variable.
>>> enter(phone) # Beginning command-oriented usage.
Entering Phone(‘ASRL5::INSTR’)
Executing ‘attention(), ok()’ % ()
ASRL5::INSTR> AT
ASRL5::INSTR< AT
ASRL5::INSTR< OK
>>> # Items defined now affect only the phone object.
>>> procedure(trick = “call(‘%s’), sleep(15), no_carrier(), hangup()”)
>>> trick(me)
Executing “call(‘%s’), sleep(15), no_carrier(), hangup()” % (‘+123456789’,)
ASRL5::INSTR> ATD+123456789
ASRL5::INSTR< ATD+123456789
ASRL5::INSTR< NO CARRIER
ASRL5::INSTR> H0
ASRL5::INSTR< H0
>>> exit(phone) # Ending command-oriented usage.
Exiting Phone(‘ASRL5::INSTR’)
>>>
[/python]

Categories
Examples Tools

Interoperability

Working with multiple connected systems is complicated in other tools and therefore often not prioritized, leading to poor interoperability and user complaints. With quflow, interoperability testing is much easier:

1. Start a server for workspaces on one system. In this example the server publishes a phone (‘serverPhone=phone’) and its protocol on all workspaces so that other devices can use it during experiments.

[python]
>>> from quflow import Driver, Workspaces
>>> protocol = dict(
… commands = dict(
… attention="AT",call="ATD%s", answer="H1", hangup="H0"),
… events = dict(
… ok="OK", receiving="INCOMING CALL %s",
… connected="CONNECTED", disconnected="DISCONNECTED"),
… expectEcho = True)
>>> phone = Driver("COM5", number="+17654321", ** protocol)
>>> workspaces = Workspaces(protocol = protocol, serverPhone = phone)
Service spiro://:9091/<workspace> started.
>>>
[/python]

2. Control the experiment from a client system. In this case one that is connected to another phone on COM7. The printouts show communication to and from the COM ports (using their VISA resource name equivalents) when a test scenario is created and tested. Printouts in brackets indicate messages that are pending – these are programmed into the scenario as events on the line after.

[python highlight=”29″]
>>> from quflow import Driver, Workspace, enter, exit
>>> call_test = Workspace(‘localhost/call_1’)
>>> myPhone = Driver("COM7", number = ‘+12345678’, ** call_test.protocol)
>>> enter(call_test) # start a manual experiment
>>> myPhone.call(serverPhone.number)
ASRL7::INSTR> ATD+17654321
ASRL7::INSTR< ATD+17654321
(ASRL5::INSTR< INCOMING CALL +12345678)
>>> serverPhone.receiving(myPhone.number)
ASRL5::INSTR< INCOMING CALL +12345678
>>> serverPhone.answer()
ASRL5::INSTR> H1
ASRL5::INSTR< H1
(ASRL5::INSTR< CONNECTED)
(ASRL7::INSTR< CONNECTED)
>>> serverPhone.connected() and myPhone.connected()
ASRL5::INSTR< CONNECTED
ASRL7::INSTR< CONNECTED
>>> serverPhone.hangup() and myPhone.hangup()
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL7::INSTR> H0
ASRL7::INSTR< H0
(ASRL5::INSTR< DISCONNECTED)
(ASRL7::INSTR< DISCONNECTED)
>>> serverPhone.disconnected() and myPhone.disconnected()
ASRL5::INSTR< DISCONNECTED
ASRL7::INSTR< DISCONNECTED
>>> verdict("OK – myPhone *could* initiate a call with serverPhone")
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
>>> exit(call_test) # finish the experiment
>>>
[/python]

The highlighted verdict line above is automatically converted into a static test purpose (where “OK – (dut) *could* (action)” becomes “Can (dut) (action)?”) and a dynamic test status that depends on the outcome of the latest run (“OK – (dut) *could* (action).” or “FAIL – (dut) *could not* (action).”). To make it re-run after an inconclusive failure, catch the bad situation once:

[python]
>>> call_test() # Re-run the test
TEST: Can myPhone initiate a call with serverPhone?
ASRL7::INSTR> ATD+17654321
ASRL7::INSTR< ATD+17654321
(ASRL7::INSTR< BUSY)
VERDICT: FAIL – myPhone *could not* initiate a call with serverPhone.
REASON: (‘ASRL7::INSTR< BUSY’) when expecting ‘ASRL5::INSTR< CONNECTED’ and ‘ASRL7::INSTR< CONNECTED’.
‘FAIL – myPhone *could not* initiate a call with serverPhone.’
>>> call_test("ServerPhone was buzy – trying again")
STATUS: ServerPhone was buzy – trying again.
TEST: Can myPhone initiate a call with serverPhone?
ASRL3::INSTR> ATD+17654321
ASRL3::INSTR< ATD+17654321
ASRL5::INSTR< INCOMING CALL +12345678
ASRL5::INSTR> H1
ASRL5::INSTR< H1
ASRL5::INSTR< CONNECTED
ASRL3::INSTR< CONNECTED
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL3::INSTR> H0
ASRL3::INSTR< H0
ASRL5::INSTR< DISCONNECTED
ASRL3::INSTR< DISCONNECTED
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
‘OK – myPhone *could* initiate a call with serverPhone.’
>>>
[/python]

3. Run the experiment again, this time on the target system. If the target is a device tested in high volume production this is done in a separate thread within a pre-compiled boot script so that it consumes as little resources as possible and can run other tests in parallel, and with logging enabled so that any error messages can be used to document the reason for repair decisions and corrective actions.

[python]
>>> from quflow import Driver, Workspace
>>> from myplatform import myPhone
>>> call_test = Workspace(‘workspaces.myfactory.net/call_1’)
>>> call_test()
TEST: Can myPhone initiate a call with serverPhone?
ASRL3::INSTR> ATD+17654321
ASRL3::INSTR< ATD+17654321
ASRL5::INSTR< INCOMING CALL +12345678
ASRL5::INSTR> H1
ASRL5::INSTR< H1
ASRL5::INSTR< CONNECTED
ASRL3::INSTR< CONNECTED
ASRL5::INSTR> H0
ASRL5::INSTR< H0
ASRL3::INSTR> H0
ASRL3::INSTR< H0
ASRL5::INSTR< DISCONNECTED
ASRL3::INSTR< DISCONNECTED
VERDICT: OK – myPhone *could* initiate a call with serverPhone.
‘OK – myPhone *could* initiate a call with serverPhone.’
>>>
[/python]