OpenBridge development

[hippy]

What would be a good start is to list exactly what needs to be purchased to participate in OpenBridge development, describe what that gets you and what you can do with it.

The BifferBoard is needed ( presumably it's the dual USB + SD card slot version being used ) having the PSU helps and I imagine the USB-console cable is handy but not sure if it is required. Cost looks to be around £65 but it's not clear if that includes VAT. The USB-console cable feels expensive but probably worth it to save messing about and risking blowing the BifferBoard up.

What's needed to connect a PICAXE to the BifferBoard ?

Then how to configure the BifferBoard and get OpenBridge onto it and working.

It's quite an expense to connect a cheap PICAXE chip to the internet and if you get that done then people who have no experience will feel a lot more comfortable and may start getting involved.

I can appreciate you want to deliver a working product which doesn't need all the above explaining as it's all done when you buy it ready-to-go but you could be missing out on any help which people who'd like to participate may have. Getting early adopters will help when it comes to deciding how to do things, what to include, what to exclude, perhaps even in writing mini How To's.

One thing worth clarifying is whether you will be providing a 'complete OpenBridge in a retail box' or requiring users to buy their own BifferBoard etc and just supplying the firmware ?

 

[Froggs]

Steliosm, Ibenson, and others. Please excuse this tome. Please also be clear that I have no desire to hijack in any way the purpose of this thread and the objective as initially described by Steliosm which clearly is pioneering and in my mind long overdue! I assume that with over a 1000 views in just a two weeks there is some real interest in the topic.

Hippy: Thanks for the clarity in your last post. You have prompted me to invest more thinking time and ultimately resorting to more Googling. You remark ‘What would be a good start is to list exactly what needs to be purchased to participate in OpenBridge development, describe what that gets you and what you can do with it.’ And for clarity I would add also; and as importantly what you don’t?! ‘The BifferBoard is needed (presumably it's the dual USB + SD card slot version being used ) having the PSU helps and I imagine the USB-console cable is handy but not sure if it is required. Cost looks to be around £65 but it's not clear if that includes VAT. The USB-console cable feels expensive but probably worth it to save messing about and risking blowing the BifferBoard up.’ £65 inc or ex VAT is a lot of money; and possibly more for those in far flung parts of the globe? Its important also that we isolate the one time set up costs.. cables etc; as distinct from the incremental cost of the bits required for each discrete project.

Hippy continues.‘What's needed to connect a PICAXE to the BifferBoard ?... Then how to configure the BifferBoard and get OpenBridge onto it and working…. It's quite an expense to connect a cheap PICAXE chip to the internet and if you get that done then people who have no experience will feel a lot more comfortable and may start getting involved.’ Exactly so, but that returns me to Hippy’s original remark, what do we mean by connecting to the internet (ie what’s included or is not?). As I understand it connecting simply via TCP/IP and serving web pages are (perhaps) increasing levels of introduced complexity… none the less however, in today’s technical climate becoming increasingly more prevalent, both from a practical, hobbyist, and educational perspective.

In the commercial world this connectivity is not costly, and I don’t see that it needs to be so from a PICAXE perspective either.. if we get it right.. [what ever that means!]. With multiple projects anything that costs >(say)£25+ (pick a figure?) may become excessive; or perhaps ‘prohibitive’ for those with less resources.. arguably so when compared to the cost of other base parts used in PICAXE and other pic projects? It is important (and increasingly so in the longer term) that this 'cost' is reduced so as to make the deployment of ethernet/internet connectivity a natural consideration of any [relevant] project not just a luxury? I cannot conceive that with such an enthusiastic forum as this (and the broader web community), that a less costly, and perhaps less dependent on a given hardware platform can not be found?

Last nights Google efforts took me to hack a day and this? http://hackaday.com/2008/09/25/web-server-on-a-business-card-part-2/ and while it uses surface mount components, is unlikely to be beyond this forums skills? A rough calculation on the BoM is £25 inc VAT. + PCB which can be home etched? It uses the freely available Microchip TCP/IP stack.

The Hack a Day then links to this? http://dangerousprototypes.com/2009/12/11/prototype-web-platform/

And then to this this? http://www.seeedstudio.com/depot/web-platform-kit-p-582.html?cPath=61_68 at USD 37 assembled?

Is this room for thought?


Hippy continues. ‘I can appreciate you want to deliver a working product which doesn't need all the above explaining as it's all done when you buy it ready-to-go but you could be missing out on any help which people who'd like to participate may have. Getting early adopters will help when it comes to deciding how to do things, what to include, what to exclude, perhaps even in writing mini How To's.’ I for one would be happy to be an early adopter and would certainly participate in writing How To’s etc but I think as I noted in my initial post what it is that the project will deliver? Again as Hippy clarifies below ‘One thing worth clarifying is whether you will be providing a 'complete OpenBridge in a retail box' or requiring users to buy their own BifferBoard etc and just supplying the firmware?’ I agree!

Please consider this possitive crticism!

Regards
J

 

[steliosm]

@Froggs: I'm in the process of creating a web site and put together all the information about this project. I will be explaining every part of the OpenBridge and also provide insights for anyone interested in taking part in the development. Shouldn't take long until a draft version of the site is online. Since, I started this project as an OpenSource project I would like everyone interested to be able to jump in and start working on it.

@hippy: You only need a bifferboard, a PSU and a PicAxe. The way to connect the PicAxe to bifferboard is up to you. You can either do it with a Serial-2-USB cable or use the on-board serial port (3.3v) available on the bifferboard. At the moment for testing/development I'm using the single USB port version of bifferboard and I'm connecting the PicAxe on the on-board serial port. I'm planning to use the USB port for web page storing and even for configuration. I still need to figure out a few things, such us web page serving. At the moment the openbridge doesn't have any persistent storage and maybe I should change that.

There are 2 approaches to use the OpenBridge software: You either put OpenWRT on the bifferboard and download the application from the (soon to be ready) web site or you simply download the firmware and you flash the bifferboard with it. I have put all my effort at the moment to first clearly describe the project and what it does and then to start describing all the details from just downloading the application to creating a firmware to flash the biffer. It's a lot of writing that need to be done but everyone that has already an OpenWRT-able device able to run a recent version of lua (5.1.4) should be able to download the application and start playing with it or expand the functionality. lbenson did it and he didn't need to go out and by a bifferboard.

 

[Tooms]

please understand i think this is very cool and i am following this, so this is not any bad comment but just a idea....

When first see the word "OpenBridge" i then google it to see what is was and to get better information but a simpel search for it was giving 62000+ hits for many things there has nothing todo with this.

so what about changing the name of this opensource project to another..

what i am thinking is that a name like "picaxe" is a very good name because there is not many other things the microcontroller pic there is call picaxe.., so when you seek for the word "picaxe" on the internet then the hits are for that microcontroller.


Just a idea and what to call OpenBridge i dont know.

 

[hippy]

The way to connect the PicAxe to bifferboard is up to you. You can either do it with a Serial-2-USB cable or use the on-board serial port (3.3v) available on the bifferboard.

D'oh! Forgot about going USB-to-serial!

That's excellent news as PICAXE programmers can use an AXE027 which will simply plug into a standard jack for the PICAXE and that can be the download socket; PICAXE which support SERRXD can even receive through the download socket.

If anyone wants to buy the USB-Console cable they can use that PC-to-BifferBoard and, turn it round, also connect to the BifferBoard USB with the molex end to a PICAXE ( taking note of the 3V3 cable requirements and it may need polarity inverting or using with High-Speed Serial ).

I'm seriously contemplating cracking the piggy bank open

 

[steliosm]

Hello Tooms.

I first thought of this device to act as a virtual "bridge" between objects and the Internet. You can have an object, which could be your electronic project, connected to the Internet almost transparently. Since the project is OpenSource I came up with the term OpenBridge.

I'm sure there are a lot of pages using this term, but I'm guessing that if you do this search in a few months using keywords such as "openbridge picaxe", or "openbridge pachube" you will come up with better results.

Mind you, that I'm still building the project's web site. When this is over, search engines will scan it, rank it and index it.

 

[Froggs]

Hello Tooms.

I first thought of this device to act as a virtual "bridge" between objects and the Internet. You can have an object, which could be your electronic project, connected to the Internet almost transparently. ....

Steliosm

And that’s the point. IF i understand it right. Some, somewhere, have said that the object could be a kettle?! The whole point is that this will work with a PICAXE OR anything else..

I assume that the back end (object) could be anything (or may not be there at all) > the only common connectivity is Ethernet (home/ intra/ inter + net) out.

So the scenarios could be:

Monitor logic state > logic state out
Monitor data parameters > data parameters out
Monitor data parameters > serve dynamic web pages out
[no back end] > serve static web pages out

Is this right?

J

 

[hippy]

@ Froggs : That's my understanding but to keep the project on-topic for the PICAXE forum the primary focus here should be on OpenBridge with PICAXE.

The PICAXE communicates with the OpenBridge system, and that PICAXE could be any micro, and OpenBridge may take inputs from other than a PICAXE or act with none at all, ie, simple web server.

That 'OpenBridge' is really software, or a suite of software, it can potentially do "anything". The initial course is to provide a path for networking capabilities for PICAXE.

 

[steliosm]

Yes Froggs, you can almost connect anything to OpenBridge. By creating an add-on board for the bifferboard you can have digital I/O and analog ports available on the bifferboard itself, eliminating the need for the user to have a microcontroller between openbridge and his 'object'.

As hippy points out, the focus is to provide a solution to network the Picaxe chip. Anyone can use the information available in this thread and the project's site and use them to connect another type of microcontroller.

 

[Froggs]

Hippy:

1. Yes. Agreed understanding..

2. I also wanted to add more understanding (before I forget again) that OpenBridge can also serve amongst other things as Steliosm points out in his initial post!

- sending email
- sending sms through an SMS gateway
- reading twitter data
- reading pachube feed data
- reading RSS/XML data
etc!

 

[Froggs]

AHA!! Stelios got there before I hit the post button! Hippy and Stelios: Thats the fun bit. While I acknowledge this is a PICAXE forum the bridge is an OPENbridge... my preference is only to ensure that at an early stage 'open' is kept open.. without 'closing' doors or making necessary rework/ redesign later on.

Perhaps? If other platforms had adopted this route previously; then the PICAXE platform could have jumped on that other platform bandwagon... is PICAXE first? (at least in practical afordable terms?). That we are where we are now with OpenBridge suggests we are?

Stelios: I look forward to studying the next release of the web site! Enjoy writing.

J

 

[steliosm]

Froggs: There is no reason for not keeping the project open to any technology or architecture.

Yes, I do believe so, that if another electronics community had started a similar project we would have taken part to ensure that their project is compatible with the PicAxe chip. I would like to thing that members from other communities will do the same with OpenBridge.

 

[steliosm]

I have a preview for the web site I'm preparing for this project. I would appreciate any comments regarding the information presented on the web site.
You can access the site here.

 

[lbenson]

By good fortune I am both a picaxe enthusiast and an openWrt user, so both sides of the openbridge solution are familiar to me. I happen to think that openbridge is a good name (if not already taken for a major competing project)--it is a +bridge+ between a microprocessor and the internet, and Stelios has made it +open+ so that others may modify the code and use it for devices other than those he has used it with.

This openness refers also to the devices which connect to the "bridging" device. Anything which can send and receive serial data can use the openbridge software on an openWrt device to control basically anything which can be controlled over the internet--the kettle (if appropriately controllable), a pan-and-tilt webcam, a heating-and-airconditioning system, or anything else. So far, Stelios's efforts have predominantly been focused on +reporting+ (a temperature, for instance, via email, twitter, or pachube), but the mechanism is in place for +controlling+ as well.

So far, the software appears to work only on the openWrt flavor of Linux, because of some glitch in the memcached operation, but there should be no intrinsic reason why it should not run on any *nix device which can read and write serial data.

The Bifferboard is ideal for size and power draw, if not necessarily for cost. The cost of linux-capable devices with ethernet and usb continues to drop--I can't think that it would, for very long, be an obstacle.

 

[steliosm]

lbenson is right. The name clearly points out the what the project does (bridge) and how someone can get a copy (open/free).

I'm working on the web server part of the project at the moment. Busybox' web server should be able to work with CGIs. I was thinking to implement a Web Service like CGI application so external applications (such as web browsers, web hooks,etc) can GET and SET the 'virtual registers'. That would probably be the first step towards the "controlling" part of the project, as lbenson described it.

I still need to figure out how to store and serve 'dynamically updated' web pages. I have a idea about how this could be done, more later.

 

[lbenson]

I'm not sure what your issues are with cgi/lua/openWrt. I puzzled out a simple dynamic cgi solution with lua using the busybox httpd web server and documented it here (post 10 in the thread): https://forum.openwrt.org/viewtopic.php?id=23114

 

[steliosm]

I have written CGIs with Lua for a different project. They work fine.
What I need to figure out is how to serve web pages that are 'dynamically' updated with 'virtual register' values. This is getting even more complicated if you consider that the OpenBridge firmware, the one that will be running on the bifferboard, does not have a persistent storage. Every time you reboot it starts fresh At least, this is how I'm playing with it at the moment.

 

[steliosm]

Hello all.

I have created a set of CGI script for the Web Interface. The concept is Web Service oriented, which means that there is no pretty HTML interface. Applications or user can make connection to the web interface to GET or SET virtual register values.

Also, there is support for EEML and CSV formats. This is done mainly in order to support Pachube automatic feeds.

You can have a go with the CGI scripts here (web site is still under development).