Categories
Discussions

Big problems – small solutions

Mobile devices contribute more and more to the every-day life. Their abundance and rapid development has led to very short product life-cycles which cause quality, health and recycling problems, and customers start to look for better and more sustainable alternatives (http://awesome.good.is/transparency/web/1010/green-brands/flat.html).

All major mobile product manufacturers nowadays use generic platforms instead of custom designs. They can shop around for platforms that fit their complete product portfolio and roadmap best, and also change platform and component suppliers since they all are designed to fit generic platform architectures. This change in design methodology make it much easier and faster to introduce and establish new technologies that are smaller, more powerful, environmentally friendly, flexible and future-proof – exactly what is needed now.

Sustainable engineering of consumer devices means a much reduced amount of production waste, careful choice of good commodity components, integration of technologies with robust and scalable performance , and in general designing for a life together with the customer rather than a brief financial transaction.

Categories
Research

Technologies for sustainable devices

Have you experienced that the first software updates make the device better, but after some year it starts to get more and more sluggish and drains the battery? It has started to assume newer hardware exist and need to emulate it with software instead and that can be very inefficient.

Turning your device to waste is not what the app developer want, and is not good for the environment either. If the hardware chips inside the device were re-configurable instead of frozen to an old design, it would not get outdated as fast. Alternatively, if the complete device was manufactured with very low environmental impact and using decomposable parts, it would not matter as much when it does get outdated. But it would still need to be small, cheap, fast and power efficient – otherwise the product won’t sell. With latest nanoelectronics and material technologies this is finally becoming feasible! Examples of new research to consider in technology roadmaps:

Joakim Pettersson, the founder of Quflow, was doing early nanoelectronics research 15 years ago and are working with experts on nanodevices that are industrialized now. Quflow can help companies analyze and industrialize in this new era of extremely power efficient, sustainable and small devices.

2D honey-comb pattern of carbon and its electron structure
Graphene and its 2D electronic band structure (from http://www.als.lbl.gov/als/science/sci_archive/154graphene.html)
Categories
Menu

Consultancy offerings

Quflow can help with one or more of the following tasks to make sure your product exceed expectations:

Step 1: Find a modern platform series for your product family where all hardware and software components already play well together and will continue to do so for many years to come.

Step 2: Find main message that will build the value of the product family and preferably a unique message for each product.

Step 3: Find soft quality criteria (excellent/good/poor) that relate most to the intended customer.

Step 4: Find soft design challenges (hard/standard/easy) that contribute most to the main value.

Step 5: Find solutions to design challenges through regularly updated and aggregated risk/opportunity analyses.

Step 6: Construct the most efficient system design, product optimizations and integration guidelines based on regularly updated design solutions using research, lessons learned, modeling, benchmarking, prototyping, identification and maturity/cost/value roadmaps for each design challenge in use-cases and scenarios where system performance is most critical.

Step 7: Connect people into small and effective teams focussed on quality parameters that can be continuously benchmarked and designs that are easy to integrate without any need for guarantee repairs. Develop methodologies and training that stimulate creativity, team-working and quality improvements across all disciplines and organizations involved.

Step 8: Product engineering and verification such as driving and participating in product adaptation, requirement coverage analysis, competitor analysis, lab testing, focus testing, field testing, certifications, volume qualification, feedback harvesting and continuous improvement activities.

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]