Mobimation AB

Android powered Digital Signage

2012-02-02T11:58:00.025+01:00

Mobimation is working on a Google TV related advertising solution.
This is developed to meets the needs of upgrading existing billboard systems to a solution that allows easy remote control of the scheduling and deployment of campaigns on individual screens as well as mass deployments.
The solution is partitioned as the BillboardRemote app, the "BoardRoid" main app that runs on each display, and the framework for Advertising Suite's (ASes) which represents powerful content in terms of richness in its mix of graphics, still photo, video and optional consumer interactivity.

Remote installation, scheduling and maintenance of ad campaigns in realtime from any location using a secure login Android application with encrypted communication.
Very low cost hardware for driving the billboard display.
Internet connectivity enables easy administration and interaction possibility.
Ad campaigns run as Android app on screen, interaction possible with
ad campaign consumer apps that can interact with the displayed ad in realtime.
This can create strong consumer engagement and brand/product attention
beyond what can occur with traditional one way advertising.
Easy upgrade of existing video based billboard systems.
See http://boardroid.com for the project site.

// BillboardRemote (intended to run on Android smartphones of various sizes) // controls the publishing/airing of advertising campaigns on billboards. // A billboard in this context is typically a large digital signage display
// powered by a Google TV enabled set top box (such as the Logitech Revue
// or any of the low cost asian Google TV boxes). // The Google TV box is connected to the Internet
// by means of the most suitable connectivity at the actual location. //
// BillboardRemote can upload/select/edit a Playlist which controls the
// advertising presentation of Advertising Suites (AS). // Each AS exists packaged as an Android application and becomes launched
// by the Billboard app according to the playlist schedule.
// AS'es enable a powerful feature to allow consumer interaction with ads
// at particular locations. An AS can have an association with an
// AS Consumer Application (ASCA) that allows interaction with the
// ad in realtime from the consumer smartphone. // // The combination of Digital Signage Display (DSD) and network attached Google TV box
// is described here as a Billboard Node (BN). If your DSD
// supports HDMI or DVI for video it can be part of a BN. // Billboard Remote can control the upload/installation/removal
// of AS'es in a single BN or simultaneously across a network of many BN's. // Thousands of such BN nodes may exist globally
// with AS'es prepared for each market. // // Used in the context of Digital Signage the Google TV box
// launches the main BoardRoid application at power on.
// The BoardRoid app runs a server which Billboard Remote
// can connect to and navigate the options available.
// This server is also used in special ad campaigns that
// allow consumer interaction with the ad from ad specific apps
// at a particular location and time. Consumer interaction
// with ads is the next big thing.

The Wifi beacon chips

2011-10-12T00:08:00.012+02:00

Someone will just have to begin manufacturing Wifi beacon chips real soon !

Now what are beacon chips ? We are not talking bacon chips which is a whole different matter.

The beacon chip is an electronic circuit that implement the beacon function of a WiFi chip. Wifi chips are radio based network circuits found in networked devices and wireless access points (WiFi routers, etc).

Its serves to periodically transmit a piece of data over the air, an identification string on the Wifi frequency band so that this ID can be detected by a mobile phone application. Smartphones which are very popular nowadays (iPhone, Android) all have Wifi access and you can download and install applications that can scan for such SSID's in the environment. When such a beacon signal is transmitted in the area where you are located the phone application can quickly detect its presence. Such a beacon chip needs to perform only this role, where the rest of a Wifi interface chip is simply omitted. The role of the beacon in this application is unrelated to Wifi, it only uses this frequency band to radiate its identity string (SSID). The unique ID can be translated by the phone application to a fixed geographical position, meaning that when the application senses this ID it knows that the ID is transmitted by a beacon device located at that geographical position. This offers sufficient positioning accuracy for many applications. Such chips would be quite cheap to manufacture ( $1 ) and there would be a substantial demand worldwide for use in this type of positioning application. A commercial prerequisite is that they need to pass radio spectrum approval in the country where they will be deployed.

Once it has been resolved how such chips can get commercial approval to operate on Wifi frequency bands then the next job is to package them in a format where they can be powered by an energy source at hand at the location where the chip transmits. The power source can be a solar panel, an inductive pickup charger or something else. Focus on minimizing cost per beacon transmitter is important.

So why all these beacon devices ? Well by placing them at suitable intervals along a path where you want to track the geographical position (preferrably at locations where GPS satellites or A-GPS is not available such as underground) you accomplish a means of keeping track of your position along this path. This is typically locations where GPS/A-GPS do not have a reach. A major application is enabling location sensing in the subway network of a city. There are numerous applications possible that would be very popular in the subway such as tourist guides, games, navigation apps, etc. if only the app could have a sense of location. There are many cities with subways, worldwide. In addition to existing access points at a location the beacon device fills a need as enabler for positioning at coordinates where other means are missing. If you know of a supplier or potential manufacturer of such beacon chips then please inform me.
I donate this idea here since I am not in a position to embark on becoming a millionaire beacon chip entrepreneur at this moment. I just need the chips to support some cool subway apps (such as the so far little known SubTrip underground commuting entertainment app)

In the meantime it is possible to use regular Wifi-enabled microcontrollers ($50) to serve as these beacons but since full Wifi devices are relatively costly units (due to features way beyond what a beacon chip offers) they can only serve as prototyping/demo substitutes.

Mobimation mobile to machine access solution

2011-01-24T10:30:00.019+01:00

The Mobimation solution has so far been described in three blog posts:

However for conveying what I am after (which is really to get you to see the possibilities) I put together this post which elaborates on the potential of the overall solution.

But wait ! Do I see the word solution here before even beginning to talk about a problem?

Ok that´s how engineers often do it. Dive directly into the fun part without describing why. But no worries. There is a background idea with all this. Fortunately in this case the solution can really solve problems.

Here´s an attempt at formulating the problem:

There is a lack of a uniform way of getting Internet access to physical equipment and sensors.
Missing today is a distinct generic controller solution for quickly Internet enabling physical machinery and bring their functionality in the hands of a mobile user.
Missing today is an easy way to set up remote sensing and control so that it can be reached from a mobile device.
A lot of equipment exists out there today that lack any way of remote interaction but the user need to be physically present at the same location to operate it. Time is spent on travel and traffic jams and means cost for service personnel. Private consumers sometimes dream of a way to monitor something at home but have not yet seen any good solution.

This rests on the assumption that

There is an interest in the world of being able to remotely monitor and control stuff from a mobile phone if it were at all possible in an easy and affordable way.
Effortless connectivity means more services being developed (adoption) which stimulates a business growth. If developers can focus on endpoint function development (client and remote IO behavior) then this can save implementation time.

What got me going on this was realizing the power of mating small Wifi interface modules with a microcontroller on a small board. This combo becomes kind of disruptive in the sense of how things that up til now has been quite standalone can now be access enabled at lower cost than ever before.

One of the more iconic designs that inspire is the FlyPort module developed by the italian OpenPicus project. It simply mates a Microchip PIC processor with a Wifi module. They have developed an IDE and ported freeRTOS to it. Another illustrative example is the Arduino based BlackWidow card by AsyncLabs. Both of these modules hints at an era to come of connected devices and you can begin prototyping such stuff now. Many such prototyping boards are based on open source designs which can be re-used in commercial solutions.

Wifi has a close relation to Internet Access and my tests proved that such a Wifi adapter combo can connect to a Wifi router using WPA2 encryption and from there reach an internet server within a few seconds after power on. That worked fine towards a 3G Wifi router, a nifty solution for deploying connectivity without a need for fixed network in areas where this is possible.

Hey that got me thinking. Combining this with physical interfacing to sensors and other IO, a uniform way of accessing such little modules from the Internet, and the power of mobile application dev platforms can be a great enabler

for remote interaction.

The Mobimation solution consists of three parts:

Adapter module (Mobimation Enabler)
Device hub server (Mobimation Exchange)
Mobile application API (Mobimation API)

These three parts together is a powerful combination:

The adapter modules each interface to a case of real world physical sensing and control.
The hub server brings all those modules online and presents a uniform way to reach all sorts of physical interaction functionality out there.
The mobile application is the end user tool for interacting with an adapter module via hub servers. And an adapter module can represent a piece of equipment out there.

In (1) the actual IO controller firmware and physical interfacing customizes the adapter for a specific solution. I am working at an attempt at a generic firmware realization that work together with a mobile application to allow mapping of typical sensor and control tasks onto a user customizable interface. However I envision the majority of deployed solutions will be custom developed (app + adapter firmware) to optimally cater for the case at hand.

(2) can have more or less rich feature set but the main principle is a multithreaded server that

sits as a hub between modules and clients to pass data streams across. This can include payment gateway functionality as well.

In (3) it is possible to define API´s that encapsulate the connectivity details and allow quick access to the peer remote end adapter. Obvious platforms to look at covering is Android and iPhone. Even the millions of phones out there with simpler Java ME platforms are interesting since many consumers use these daily.

By making sure the adapter module (1) has a generic Internet connectivity part then all such modules can autonomously register with the hub server (2) for further access by clients (3).

Beginning to see the power ?

Now envision 2300536 such distinct adapter units out there, each booted up and registered its online presence with a farm of load balanced device hub servers. This means suddenly a huge plethora of functionality online. The idea is of course not that each user would access each device, analogous to how each user would not access each web page in the world. But the uniform way of making resources available simplifies the implementation of the combination of (1) adapter module and (3) client application that look up and connect to each other via (2) the hub server.

In a commercial deployment the hub server also represents a place where a community of customers can build and where payment gateway solutions can be integrated.

Typically an adapter module (1) and client application (3) can be seen as an inseparable entity distinctly developed together to implement a remote service. The access infrastructure represented by the hub server (2) simplifies getting these two endpoints to talk to each other and thus makes it interesting for service developers.

Easier to develop a solution and get it out to end users.
More solutions developed grabs consumer interest.

A demonstrate-able prototype of this solution is under development.

I limited this to mobile client access, however the server hub can of course also be accessed by web services that interact with physical sensors and machinery.

Mobimation AB the company is looking for partners worldwide interesting in collaborating on the commercial realization and exploitation of this solution. People experienced in what specific interfacing needs exists. How a solution is best packaged in terms of hardware design. Production resources, sales, venture capital.

Axis 207W

2011-01-13T15:27:00.007+01:00

The swedish surveillance camera manufacturer Axis has an understatement of quality in their products. One of the hallmarks of their designs is paying attention to picture quality. Even this entry level model includes an advanced multi-lens design.

The first Mobimation Android camera app is based on using this camera model. Choosing Axis is not just for the camera but they got a comprehensive camera API, see http://www.axis.com/techsup/cam_servers/dev/cam_http_api_index.php

The camera app is a core function I am working on for the Mobimation remote access offering.

It shall for example be technically possible in a remote interaction solution to see what´s going on at the other end while a control action is being carried out. Video/Still picture will be a standard "sensor" feature of the Mobimation Enabler product, where actual enabling depends on what sensors a customer decides to add.

Interesting controller solutions

2010-12-23T02:14:00.005+01:00

In this post I will collect various interesting controller solutions I come across.

First out is the SX-PY board:

http://www.areasx.com/index.php?D=1&page=articoli.php&id=8173

quite small footprint and should have things going for it.

FlyPort module with Microchip PICkit

2010-12-23T01:09:00.007+01:00

Late in the process I learnt that the Openpicus "Flyport" IO controller module is PICkit compatible. (See PICKit2, PICKit3)

This can be very useful in the sense that the FlyPort which essentially consists of a combination of a Microchip 24F256FJ106GA processor and Microchip MRF24WB0MA Wifi module can be used together with the PicKit tool to flash and in circuit-debug firmware on the FlyPort using the Microchip MPLAB IDE.

Here´s pinout information

PIN PICKIT FlyPort
/RESET 1 26
Target VCC 2 24
GND 3 22
PGD 4 20
PGC 5 18
AUX 6

This italian blog lead me to it:

http://www.areasx.com/index.php?D=1&page=articoli.php&id=8254

Microchip explains it like this in their PICkit2 manual:

"The PICkitTM 2 Microcontroller Programmer can program PICmicro® microcontrollers that are installed in an application circuit using In-Circuit Serial ProgrammingTM (ICSPTM). In-Circuit Serial Programming (ICSP) requires five signals:

• VPP – Programming Voltage; when applied, the device goes into Programming mode.

• ICSPCLK or PGC – ProgrammingClock; a unidirectional synchronous serial clock line from the programmer to the target.

• ICSPDAT or PGD – Programming Data; a bidirectional synchronous serial data line. • VDD – Power Supply positive voltage.

• VSS – Power Supply ground reference."

They also explain

"With Microchip’s powerful MPLAB Integrated Development Environment (IDE) the PICkit™ 2 enables in-circuit debugging on most PIC^®microcontrollers. In-Circuit-Debugging runs, halts and single steps the program while the PIC microcontroller is embedded in the application. When halted at a breakpoint, the file registers can be examined and modified."

XBee - versatile wireless network communication modules

2010-12-22T19:45:00.007+01:00

XBee is a small hardware module that employ radio technology for communication among a wireless network of two or more XBee modules.

XBee modules have an unusual feature that deserve spreading a gospel about since it allows for a remote capability that not all developers have realized. And if they knew about would add one more design alternative to their toolbox.

An XBee can operate in two distinct modes. Part from the conventional role as a pass-through serial communications link, it can also operate in a command mode where it implements a remote control/access instruction set for sensing and controlling data of its own IO control signals. Commands and data for setting and reading of electrical signal values gets transported back and forth over the wireless link to the initiating node. Thus all decision making takes place at the initiating remote node. Analog and digital values can be read, PWM and digital control lines can be set, all by commands from a remote end.

Controlling an XBee this way from another node has it work as a "remote IO port" where port hardware logic effectively owned/managed by a remote peer becomes distributed out to this other side of a radio link.

This can be feasible in some applications where a quick response decision making logic is not needed locally but can be accomplished from a remote end, thus allowing a more compact and lower cost hardware function at the specific network node.

This opens up for a lot of interesting applications where "a network of bees" implement distributed sensing and control logic in machinery, and where a possibly central control logic can administer overall operation, all run over that local radio network.

So, to summarize, besides simply passing data between nodes for microcontrollers, the XBee has other features that can aid in process monitoring and control.

The modules have digital I/O, analog input and PWM output that may be used in a variety of ways:

• Direct digital output control: Through AT commands, the I/O may be set to digital output and controlled as high or low. For example, the command “ATD0 4” would set D0 to be a low output and “ATD0 5” would be a high output.

• Digital and Analog input for transmission: The inputs may also be set to be digital inputs or 10-bit analog to digital input. Using sampling, the values of the inputs are sent as data to a receiving XBee in API mode where the ADC data is extracted.

• PWM/analog output: The 10-bit PWM value of an output may be set and optionally filtered for analog output of the unit.

• Line Passing: The digital inputs can control a digital output on a remote unit, and analog input can control a PWM output on a remote unit.

Remote Configuration

Using AT commands, the configuration of a remote module may be changed by sending the command in an API packet. This could be used to control remote digital or PWM outputs, or change other parameters of the remote XBee.

Some links to XBee material for further study:

- http://prospekts.wordpress.com/2010/07/25/xbee-a-brief-primer/
- http://forums.trossenrobotics.com/tutorials/how-to-diy-128/xbee-basics-3259/
- http://www.makingthings.com/documentation/tutorial/xbee-wireless-interface
- http://www.ladyada.net/make/xbee/
- http://www.tristantech.net/articles/xbee_tutorial/1.php
- https://sites.google.com/site/xbeetutorial/
- http://forums.parallaxinc.com/forums/attach.aspx?a=44836
- http://www.jsjf.demon.co.uk/xbee/xbee.pdf

Cool norwegian project that shows the power of a Perl library: http://jager.no/news/digi-xbee-part-2-using-xbee-perl-modules-to-control-a-relay-board

Seeed Studio RFBee - exciting local wireless IO control potential

2010-12-16T16:46:00.010+01:00

An RFBee module is an unusual interpretation of the XBee module standard.

XBee is a popular long range radio module that allows for advanced "mesh" networks of such modules. XBee makes use of the powerful and advanced ZigBee networking standard. XBee modules come with a preprogrammed fixed set of AT commands that can be used for setting up

"remote controlled/distributed IO port nodes".

RFBee uses the same socket type and offers a pin layout conpatibility, but it uses a much simplified radio circuit with lower range, features and cost. An RFBee consists basically of the combination of a Texas Instruments CC1101 RF transceiver circuit, an ATmel AtMega168 IO processor, an Arduino bootloader and firmware that turns this into an autonomous processing module with radio communication capability.

This module by default comes programmed with standard AT command repertoire as described here.

An exciting feature of the RFBee is that the firmware is open source and can be modified, expanded or replaced by your own implementation.

Such custom RFBees nodes can run bidirectional communication between each other and exchange whatever information and do whatever IO control operations needed. So this is hardware with considerable room for innovation in the firmware you flash on it. With the default firmware there is appr 40% space left in flash for adding your own extensions.

RFBee modules is flashed with new firmware from an Arduino IDE by connecting it to your computer using a Seeed Studio "UartSBee" module.

The versatile UartSBee board can serve three purposes:

1: With USB connected then a connected Bee module gets power from USB

and you can communicate with it and re-flash its firmware.

2: You can power it and communicate with a Bee module

using UART signals via connection pins of the board.

3: You can run a Bee module standalone using this module as a breakout board for access to all the pins of the Bee module and supply power via the provided power supply pins.

A convenient add-on companion hardware for the RFBee is the Seeed Studio "Relay Shield" board by Seeed Studio.

This board comes with four on-board relays and screw posts for installation. This board features a socket to accommodate a Seeed Studio "RF Bee" module

and makes for exciting possibilities to switch electricity, and accomplish wireless control interaction between nodes. The board also adds convenient power supply conversion and breakout pins for unused RFBee IO module pins. We supply the Relay Shield here

WiFi IO Controller emulates R/C receiver

2010-12-12T12:50:00.011+01:00

I´m developing a new application for the OpenPicus FlyPort IO controller module.

This module proves handy for Wifi enabling physical products. I will use it to promote my physical device hub server solution "Mobimation Device Exchange" (MDE). So I´m developing some firmware for the FlyPort where it will emulate the channel outputs of a typical R/C receiver module, using pulse width modulated (PWM) signalling.

This way I can accomplish a solution where the module accepts navigation commands and implements the corresponding RC receiver channels. This means the Flyport can work as a drop in replacement for the existing R/C reciever of a plane/helicopter which can then be navigated over Wifi. I am developing a R/C transmitter control emulation in Android to allow a mobile phone experience similar to control using an ordinary transmitter. It will be possible to access the module in two alternative ways, directly over Ad Hoc Wifi from a mobile phone, or remotely where the module registers itself with the MDE server and client can establish a command stream session with this Flyport based R/C service.

Developing this requires careful study of the 310 pages Microchip manual for the PIC24FJ256GA106 processor: http://www.openpicus.com/doc/pic24fj256.pdf

in combination with the FlyPort schematic http://www.openpicus.com/doc/flyport_sch.pdf

in order to configure available pins for output control. I look at using timer interrupts for controlling a duty cycle of each sw generated PWM output.

PayPal integration with the Mobimation Device Exchange

2010-12-09T12:42:00.003+01:00

Development is ongoing to integrate PayPal functonality with the Mobimation Device Exchange (MDE) server under development. This enables use of PayPal to activate functionality in remote equipment (simple examples can be point of sales equipment such as vending machines, car wash stations, etc.) from a mobile phone. The situation of server logic in the fixed network is essential for the exchange of trust tokens between the payment service provider and a client and the MDE server serves that role well. A goal is to have an initial solution ready for demonstration in January 2011.

Mobimation Device Exchange - facilitating equipment communication over mobile 3G

2010-11-24T11:29:00.018+01:00

Mobimation is developing Mobimation Device Exhange (MDE), a new proxy server software that hosts communication access to equipment that integrates Mobimation Enabler (ME), the Mobimation equipment access adapter.

The ME is a tiny microcontroller module that can be integrated in all sorts of physical devices you come across in everyday life, to allow human beings to be able to interact with that device from a mobile phone or web service in a way appropriate for that particular device.

Mobimation expects such ME´s to become a very popular way of breathing "intelligent life" into both existing equipment as well as for integration in new products in development.

"Intelligent life" here means giving equipment the ability to report status, allow configuration, interaction, remote as well as local access over a network. Lots of equipment exists that can today be operated and monitored only by direct physical attendance at the same place. "Dropping an ME" into the equipment can enable a whole new way of interacting at very low cost. More on this in the ME article.

To arrive at what the MDE does, this post first elaborates briefly on the subject of communication with equipment which uses mobile 3G networks for access.

Many cases of machine access involve a geographical location where mobile network access is required for cost effective deployment. The outside world may have a need to establish direct contact with the deployed equipment for further interaction.

Use of 3G mobile network mobile subscriptions and a corresponding 3G access router can be cost effective for rapidly bringing a system online without having to get involved with whatever fixed network access might be available at the location and the costs for getting connected that way.

One consideration is however important to look at. Access in a mobile network occurs through APN´s which are essentially proxy servers that determines, as per mobile operator policies, how data access is allowed to occur. In case of some mobile operators these APN´s prevent external parties from initiating a network connection towards a party inside the mobile network. Same as if your friend runs a web server on a mobile phone and you find it difficult to be able to connect to it. End of story or what ?

No this can be worked out. A general way to work around this is to have the equipment itself initiate and maintain a connection to (analogous to "register itself on") an external server from where external parties can then establish further communication. Thus meaning the equipment is the initiating party and actively makes its service accessible on an external server.

You may compare this to how mobile phones users do things. There the user operates the phone in order to fetch web pages, send email, check out the latest Facebook posts, from within the mobile network.

The difference here is really that the initiatives of a phone user is represented by a programmed microcontroller with IO capabilities that determines what stuff to send and retrieve, representing functionality of the physical equipment it is part of.

The server external to the mobile network can either have as a role to put the equipment and a client in direct (synchronous) contact for direct command/response interaction (proxy server), or, can be any service that the equipment logs into and interacts with.

For example a simple dedicated service can be an "asynchronous remote data access location"

where the equipment dumps its data for later access by external parties in an on-demand way.

A variant is that the equipment simply logs in to an existing remote service on the Internet and interacts with whatever protocol is implemented.

In case of the proxy server, either the equipment assumes a role to stay connected relentlessly to this middleman server waiting for a request, or, is notified for example over SMS that its services is now requested and it should "come online". Such an on demand scheme can save power and resources on the equipment side for communication cases where a rapid initial response time is not required. In cases more than one client needs simultaneous direct access the equipment can spawn further connections with the proxy depending on its capabilities.

So what is Mobimation Device Exchange about ? It implements a proxy server to which Mobimation Enabler (ME) adapters (hopefully soon part of various equipment out there in everyday life) can connect and register availability. Clients that are interested in accessing a piece of equipment represented by an ME adapter go to the MDE server and looks it up. The client (for example a mobile phone application) can then establish a socket level communication with an ME where the subsequent traffic is relayed by the MDE proxy. This occurs in a two-step way. The first is connecting to an announced access request port where the client authorizes itself. Upon granting access this service returns a reference to a service instance where that client can continue interaction with that ME. This way several clients can establish simultaneous sessions with the same ME unit. Several such sessions can be ongoing simultaneously between potentially thousands of clients and lots of ME adapters via the MDE server. The MDE thus becomes a central Internet access hub for communication between clients and ME equipped products. Mobimation Device Exchange is not limited for use in mobile network commectivity but for the sake of an uniform hub solution is applicable to use also with ME adapters that connect using a fixed (cable) network connection.

MDE can also be used by equipment that integrate ME as a hub to establish communication between ME´s (Machine to Machine) regardless of location.

MDE also manages support for paid access to select features in equipment such as vending machines, car wash stations or similar service facilities. Its placement in a fixed network environment have it meet sufficient security requirements for handling the exchange of payment tokens with payment services and access authorization for the particular ME adapter using a secure protocol.

FlyPort Wifi microcontroller Internet access

2010-11-23T14:04:00.006+01:00

I´m doing work to have Flyport nodes register their presence on an internet server

so they can be reached from mobile apps.

For a background, see this post.

The principle is easy; the FlyPort uses its TCP/IP stack to connect to a 3G Wifi router with WPA2 encryption and gets and IP address on the router. It then logins in to the admin web server in the router, and retrieves the current Internet IP address assigned to the router.

This address is used on the node server mentioned below to access devices connected to this router.

The FlyPort then connects to the remote "node server" on the Internet and registers itself and the IP addres. A mobile app can now access that server to retrieve access info for the FlyPort equipped equipment of interest and do further interaction with the HTTP server on that FlyPort module.

This shows the analysis of HTTP traffic between an ordinary IE browser and the 3G modem that I did to find out how to accomplish the router login HTTP data for the FlyPort.

A better way is to set up a DynDNS account and configure the router to automatically update that service with its current assigned IP anytime it changes. That way the router can be assigned a logical name which will remain valid. Many routers have support for DyDNS updating.

The power of open source

2010-11-18T20:04:00.004+01:00

Lots of people keep sharing their accomplishments in the open source communities,

here´s an example of interacting with a GSM module:

http://tinkerlog.com/2009/05/15/interfacing-arduino-with-a-telit-gm862/

Such gifts to other developers help forwarding development.

The Mobimation Enabler (ME)

2010-11-18T03:00:00.007+01:00

Mobimation AB is developing "Mobimation Enabler" (ME), a robust mobile service adapter product for "wireless access enabling" of physical machinery. A missing mobile service enabler today on the market is compact IO controller solutions that have the following characteristics:

Compact dimensions
Low cost
Autonomous network prescence
Robust IO interfacing (Relays, buffers, protection)
Wireless connectivity (Wifi)
Developed infrastructure for Android/iPhone/Java ME access

The aim of Mobimation Enabler is to excel in fulfilling these characteristics. Such adaptors should be very popular in quickly service enabling existing equipment for user interaction via mobile devices.

A key goal of an ME is to establish a network presence. The ME see as a primary goal to itself work to stay connected to an Mobimation Device Exchange (MDE) server. This way potentially many thousands of ME´s are instantly reachable for the mobile device user.

ME´s can revolutionize how physical machinery can be made available online.

An article is upcoming on how to actually go about integrating an ME into a physical device, stay tuned.

Mobimation is working on integrating PayPal Mobile Payments with the MDE as an optional feature for use with for example vending machines, car wash stations, or similar applications where a payment action enables access to a service.

More news on Mobimation Enabler will arrive in the coming months where we will be able to demonstrate this product in action. If you are interested in collaborating in this exciting project or have products that would benefit from becoming "available" then please contact Mobimation AB.

SparkFun - tools for an innovative spirit

2010-11-17T15:08:00.003+01:00

Mobimation has signed a reseller agreement with SparkFun Electronics for the swedish market. SparkFun is a U.S company in Colorado who sell all sorts of electronic project infrastructure components. In fact merely browsing their catalog brings about a sense of Fun for any hardware inclined developer ! You just want to jump in and begin developing. The conveyed sense of innovation spirit is tremendous.

I´ll highlight a few nice items they stock. Mobimation have an interest in Wifi conectivity and always look out for small compact hardware to underpin our ideas. One approach to development is to begin with prototyping using components readily available that cater for the access to the type of IO and sensor access needed. This can be sufficient for coming up with a working and demonstrate-able prototype. Once you see this is going to be a volume product you could develop your own board using maybe the exact same hw sourced as components. That is in itself a complex undertaking part of an industrialization process but may be necessary for margins and not least production quality and assembly costs.

I think Arduino is serious stuff for prototyping many solutions. These little processor chips by Atmel Corporation and the Arduino dev environment is so easy to use and interface to that many relatively low performance requirement product can easily be based on this. For industrialisation there are many chip alternatives to consider. I don´t see open source licensing considerations a hurdle either. In some cases it might be feasible to protoype with Arduino and base the resulting code on totally platform agnostic code.

In the meantime let´s look at what stuff is available to config your prototype rig.

I love Wifi enabling stuff for flexible connectivity. Wifi chips are still costly but for prototyping SparkFun carry the Roving Networks RN-131C wireless module (known as the "WiFly") based Arduino shield that you stack onto a regular Arduino board. At USD 89.95 single Qty it Wifi-enables the Arduino. You need to yourself solder header pin strips to it.

Such a module could then find its way into your final design as an SMD component:

From SparkFun 100+ quantity of this SMD mount module is down at $39.96

Blackwidow 1.0 - Wifi enabled Arduino clone

2010-11-15T13:03:00.013+01:00

I clearly see Wifi becoming a very nice connectivity enabler for connected machines that simplify access to mobile applications. Recent smartphones can really quickly scan the environment for Wifi nodes and can thus quickly sense and connect to Wifi devices, either directly in ad-hoc mode or via a router. The trend of implementing command server logic directly in the connected IO controller device means very compact solutions can talk directly to a mobile phone if needed.

There exists already several examples of very compact IO controllers with on-board Wifi. This means a possibility for very conveniently hooking up equipment to either the public Internet or secure private networks. WPA2 encryption can in many cases offer a safe-enough secure transmission for many use cases. These units allow either ad-hoc connectivity between peers or to infrastructure routers.

For implementation of low cost equipment an attractive approach is to initially prototype solutions using development style IO controller boards and accessory function boards.

Many Machine-to-Mobile cases does not require extreme data transfer speeds or microsecond realtime responses and thus very low cost IO controllers can be employed that lend themselves well suited for a role in the integration chain between the physical gear and mobile user.

A very popular such small scale platform family is Arduino. This approach features a generic IO processor motherboard where any additional specific futures not catered for by this generic board is added as so called "shields" stacked on top via a standardized connector system. Thus the developer can quickly stack up the features needed and get up to speed with prototype realisation. The associated "Wiring"/"Processing" based SW library for C programming can be fully sufficient for lower frequency IO control tasks.

Many of the designs are open source both in SW and hardware and developers are free to convert a prototype into more cost effective production format.

This has also lead to a lot of "clone boards" produced by various sources that for example shrink areas required by basic Arduino processor functions by use of surface mount technology, then add additional attractive features on the same board that can avoid the need for any additional shield boards. The BlackWidow reviewed here is such an example where Wifi is added directly on the main board.

Once a prototype solution is established measures can then be taken in a project to rationalise/adapt the solution to a possibly mass production format by developing a custom PCB that accommodate the entire solution for the particular environment. This typically involves electrical I/O buffering, adapting for interference/temperature concerns and rationalising for cost. This is a complex undertaking including component sourcing, use of factory facilities and more that require volume to justify costs.

For small scale and one shot implementations these lab board systems can actually be employed as-is as part of a commercial solution provided that they are externally complemented with the electrical buffering/interference protection needed in a real physical installation.

Due to the cost of these Wifi enabled dev boards compared to "own PCB and sourced components in a mass production scenario" they are of course best employed as-is in low volume applications. But since they are open source a final solution is fair game for anyone to try to cost reduce using own PCB design and component sourcing/manufacture. A reason for own PCB is of course also to accomplish an acceptable equipment integration in terms of quality and production efficiency.

Now to the point of this review; one "Arduino-on-steroids" example I evaluated the other week is the Blackwidow 1.0 card which is a Wifi enabled Arduino clone.

As mentioned Arduino is a nice platform standard for quickly being able to realise and program IO controller solutions where there is not specific high speed data transfer requirements.

In this case using existing public domain Wifi stack SW I was able to have the Blackwidow connect to my WPA2 router within some 30 minutes of tinkering after my first time encounter with it. This is typical for these open source tools; others went before you and their results are available for you as a basis for being able to take things further into specific solutions. To stand on the shoulder of giants instead of reinventing that wheel all over can be key.

I supply these and other Arduino shields and processors in my shop at http://medial.se/?artnr=99-100&cat_id=41

The Blackwidow can be hard to come by due to popularity but I have a good asian source for these and can stock up. /gunnar +46 733 406530

OpenPicus FlyPort in wireless Vending Machine Demo

2010-11-14T17:09:00.034+01:00

Hello this is the initial blog post of Mobimation AB. We are a swedish company that specialise in Mobile to Machine communication. The recent arrival of very compact hardware that can enable wireless access to physical devices is a great catalyst for innovation. The most concrete rising star is Wifi married with microcontrollers and network stacks. Very compact solutions can be developed to help access-enable physical equipment that until now lacked such access possibility.

We are happy to mention a recently initated cooperation with the OpenPicus project where we operate as reseller of the related FlyPort hardware on the Swedish market via our medial.se online shop.

We have adopted this solution as basis for demonstrating to our customers how we can develop machine/sensor access solutions using this and similar controller solutions.

This time I will tell you about what we did at the Mobilefuture 2010 conference in Kista north of Stockholm now on November 11. This conference runs on the same day as the swedish "mobile gala evening" Mobilgalan where various price winners of this years Swedish mobile market becomes announced and celebrated. So there was a lot of mobile industry people attending. So some people got to see and understand what OpenPicus can do.

Prior to the show we figured how to demonstrate the FlyPort Wifi module solution in a mobile context. A concrete physical demo is always good for leaving a mark in the visitors mind. So something at least a bit spectacular was needed. My solution was we imported a chinese origin mini Vending Machine fridge from the U.S that can serve chilled Coke bottles or similar soda cans. I modified it so it could be controlled using OpenPicus FlyPort hardware. The main change was to override the physical vending control switches using relays, and I added extra lighting inside the unit which can be turned on/off from the FlyPort for an extra visual effect.

I re-used the existing OpenPicus web server demo where I, instead of controlling LEDs, used just about the same port mapping for controlling the two relays and added lighting.

I modified the default demo code so at boot up the FlyPort module connects to a Wifi router (infrastructure mode) and with WPA2 encryption. I found out the FlyPort is capable of accomplishing a WPA2 connection within a few seconds when using a pre-shared binary key. Using a human readable passphrase is a bit too slow since in that case the conversion to binary key has to be done in the Wifi stack by the CPU which takes time. So, binary key is a recommended approach and in no means less secure than using passphrase.

Once the FlyPort is connected to the router the (initially simple) Android "VendingDemo" application I developed could connect to the FlyPort module embedded web server by connecting to its IP address via the same router.

The mobile app shown at this event simply allowed selecting what Soda can (Left or Right side) to be served. When the command is sent the FlyPort interprets the command and issues a relay pulse on the appropriate vending switch which causes ejection of the ordered refreshment..

Well not rocket science but enough to have the cans come crashing down.

Since development of the app began 6 hours before the show opened there was little room for sophistication in its feature repertoire.

This wireless control of the vending machine from the mobile phone proved popular and caused some enthusiasm. We set things up so that the conference visitor could download the vending machine app from the Android Market, install it and run it to have their own personal soda can pop out as a gift.

This demo was set up as an example to show how the very compact FlyPort wireless microcontroller solution can be used to wireless-enable a piece of machinery that normally lacks such a wireless access feature. We see a fantastic potential in this type of Wifi enabled controllers for enabling wireless equipment interaction both machine to mobile and between machines.

The demo was done to convey the message that Mobimation is able to carry out projects for customers that involve mobile/machine integration work. And also puts some attention on the potential of Wifi enabled micro controllers.

In the following section you will see some detail photos of the Vending Machine Demo implementation and how I neatly installed the FlyPort Wifi module so that it is visible on the outside of the machine for good demo impact, interconnected over a flat cable arrangement with the FlyPort Nest board and other hardware internal to the vending machine.

Enjoy photos of this "inside story section". Click up to two times on photos for magnification.

This photo shows the U.S imported vending machine that I chose as demo hardware. I found no Ebay seller willing to ship one to Sweden so I used the brilliant MyUS.com shipping forwarder as middleman. Then inner operations of this machine is very straightforward to understand. No intelligent processing hardware. Electronics runs solely on 12 volts. I accomplished the external 120 Volt AC feed using a 220V->120V transformer. Normally the two hardware switches on the front panel controls a timer/relay card that spins a rotating can release actuator using an electric motor per side. I used two relays to override these switches internally.

This photo shows the finished modified demo vending machine. The Flyport module has been installed in center stage position and ca be viewed from the outside. It is connected to the FlyPort Nest board inside the box using a flat cable arrangement.

Please note the USB connector added on the side of the vending machine front door.. Using this port a PC can be connected over USB to the Openpicus Nest board and facilitates flashing of new sw and monitoring of trace printouts when needed ! Also a reset button was added close to the USB connector for easy restart and sw flashing. The photo shows the machine hooked up the a development PC that runs the Microchip MPLAB IDE and Brutus downloader for editing, compilation and flashing the PIC controller of the FlyPort. That dev PC was not present during the demo. In the photo you see the PC showing the default OpenPicus demo web server page served from the FlyPort web server over Wifi.

Placing the FlyPort module in the illuminated "showcase" area of the front panel helped increase understanding of what enables the wireless solution. A flat cable connector underneath the module connects it to the FlyPort Nest board inside. This worked very well.

The two stage cable arrangement switches pin arrays so that the module match up correctly with the nest even though it is mounted externally in a different orientation.

This photo shows the vending machine during wiring installation. This look pretty messy but it´s a prototype where the resulting demo functionality and exterior appearance was the end goal.

This "Breadboard Power shield" was used as DC converter 12->5 volts.

Mounted on the one-off prototype lab board is also a darlington array driver chip that sink the 12 volts for the LED arrays. It is controlled using TTL level outputs of the FlyPort module.

These handy relay modules by Seeed Studio (we sell them in our shop) was used for overriding the physical vending switches of the machine using FlyPort output ports.

The Mobimation appearance at the show. The cool can service demo and a display of developer board products available from medial.se

If you know of an European (M2M?) conference going forward where you think this physical demo could help catch a crowd then please let me know, maybe we could show up and run some variant of this FlyPort demo. Numerous demo features could be added such as turning on/off the fridge function, sensing fridge temperature, and more. I currently work on integrating PayPal Mobile Payments with it and in particular the Express Checkout feature. Showing this in combination with a concrete physical device can get people inspired and see the potential of mobile access solutions that employ Wifi-enabled microcontrollers.

Regards,

Gunnar Forsgren

Mobimation AB, Sweden

http://mobimation.com

gunnar.forsgren@mobimation.com

+46 733 406530