Distributors

U.K

www.byvac.com

BPS12 Wi-Fi

The BPS12 is a programmable WiFi Link that fits onto the BP2 module. This means that the user will have access to WiFi and be able to program GPIO (General Purpose Input / Output) over that link. This clears the way for browser applications or (apps) that can be used from anywhere network access is available.

Because the BP2 is essentially a microcontroller and not a Linux device, it is designed for GPIO work with all of the features of a microcontroller such as SPI, I2C, ADC, PWM, timers capture etc.

The microcontroller has a pre-loaded rapid application redevelopment system “ByPic” that enables easy programming just using text files, no programmer is needed. It can also be programmed / re-programmed in situ.

Resources

Getting Started

First see the hardware section for how to connect the BPS12 to the BP2, the BP2 requires an extra connector and so some soldering is required on the BP2.

Connect the USB to serial as normal (** see the warning about the power supply **). This will help to see what's going on. Also use BvSerial rather than BV_COM2 as BvSerial has a couple of useful utilities specifically for use when using an SD Card.

There are several methods of use and ways to configure this device for use. In all cases an SD card is required that is readable by a Windows system, i.e. FAT16 or FAT32 file system. It does not need to be blank, an old SD Card will do. The required files only take up a few k and so just about any SD Card will do.

Step 1

Download the zip file and unzip the contents to the card such that he directory structure is as shown. There may be more or less files depending on the version.

The HLK-RM04 directory is not required, it contains information on the wi-fi module.

Step 2

There are two methods described here, both will work and depends on how you want to use the device. Joining an existing network will allow access to the wi-fi from any PC on that network. Using the BPS12 as an access point will allow only those PC’s that have Wi-Fi and are connected to the access point.

Method 1 – Using the Access Point

<<<<   IMPORTANT DO THIS FIRST   >>>>

This may not be how the device is eventually used but it requires no setting up. There are so many variables that can be altered that will stop the Wi-Fi module working and so is a good place to start to get confidence in the way it works.

  1. Connect the PBS12 to the BP2.
  2. Copy the files as in step 1 above on an SD card
  3. Inset the SD Card into the BP2
  4. Connect the antenna * The module has a built in antenna that will work within a limited (2m or so) range.
  5. Switch on (connect the power) and wait for the green LED on the Wi_Fi module, next to the connectors to steadily flash and that the Con led is illuminated.
  6. On first use you may need to reset after 1 minute then wait for LED again.

L1 indicates that the main1.bas program is running, Con (LED) indicates that the wi-fi module is connected to ByPic the web server will then be run. To test this, on a lap top, tablet or smart phone look for a wi-fi network called "bv503" and connect to it. It is open and so no password is needed.

The Wi-Fi module will issue a suitable IP address for the 192.168.16 network.

In a browser address bar type:

192.168.16.220:8000

This will bring up the index page to operate any relays that may be connected.

Problems:

If the web page is not found then make sure that you are still connected to BV503. Operating systems have the habit of re-connecting back to an existing WiFi connection so keep an eye on that.

Try also 192.168.16.220 (without the :8000) This should bring up the Wi-Fi management console. If this fails then disconnect the BV503 and re-connect. Don't forget to check if the laptop or tablet is still connected to BV503 after the BV503 boots up.

Check again that the URL in the browser address bar is 192.168.16.220:8000

*** Do not progress any further if the above doesn't work as we know that at this point the BV503 is working but the Laptop, tablet or phone isn't connecting properly. This will be down to a simple mistake in the settings. Get this going first, if you progress onto modifying the default.cfg file as described in method 2 and it doesn't work it will be very difficult to diagnose the error ***

Managing Through a Socket

Access to the ByPic can also be obtained via a socket. For this you will need the free BvSerial terminal emulator. This is free and can be found here "http://www.pichips.co.uk/index.php/Downloads" Linux users can also use this as it is a Python program.

Make sure that the serial jumpers are in place at [4]

Of course the lap top or host device should be connected to the 192.168.16 network !!

Run BvSerial

Type socket://192.168.16.220:8001

The web server will be running to stop it simply press enter to break out of the web server loop.

Shown is the command to illuminate LED.

Method 2 – Joining an existing network

** Make sure method 1 is working before trying this **

This is where there is already a known Wi-Fi network, by known you will need the SSID, security type and password of the Wi-Fi hub and also the IP address of the network.

This set up is a bit more difficult as all the variables need to be set in order for communication to take place.

  1. Discover your network address. See Discovering your network for how to do this
  2. Copy the 'default.cfg' from the join_config directory to the top level overwriting the old 'default.cfg'
  3. Edit the new default.cfg file on the SD Card and set the IP address, e.g.

net_ip=192.168.1.220,255.255.255.0,192.168.1.254

Put your own IP address here, put the router or gateway address here

Set the wifi parameters, if the SSID:

wifi_conf=BTHomeHub-22AA,wep,02abcd1f15 (example, put your own information in)

In the above, the SSID is first, followed by the security type, followed by the password. Check in the default.cfg for the security types that are allowed. These parameters should exactly match those of the network you will be connecting to

  1. Place the card in the bv503 and cycle the power.

The BPS12 will initially configure the Wi-Fi module and attempt to connect to the existing network. After 30 seconds the green LED on the Wi-Fi module will be flashing steadily and the Con led illuminated.

Assuming the net_ip address is 192.168.1.220 then open a browser and in the address bar type:

192.168.1.220:8000

Normally browsers work with port 80 by default so most browsing is done without specifying a port. In this case the port is 8000 and so it needs to be specified as above.

All being well an index page will be shown.

If the :8000 is left off then HKL management page will be shown.

You will also be able to connect directly to the ByPic operating system via a socket the same way as described in method 1

Sometimes the wi-fi module can be annoyingly hard to get going but once it does connect it is very reliable providing there is a good signal. If there is no response then wait at least 30 seconds (until the wi-fi module green light if flashing steadily) then power cycle. Do this at least twice then have a look at the trouble shooting guide.

Several programming checks can are made at start up and this is explained in the text here.

Hardware

In Use

The options for the BPS12 are considerable and this will be up to the user how the module is used. In a nutshell the ByPic can run programs that will communicate using UART1 (TX/RX 1 on the Wi-Fi module). This can be accessed via a socket and so for example a web server can run on ByPic, serve up pages and react (turn things on/off, get analogue data) to those pages. That is just one example. There is also another interface that can communicate directly to the ByPic so that it can be re-programmed via the network.

Web Access

Access to the web can be implemented in many ways, this description is just one way of implementing a simple web server. The goal of course is to ultimately control the ByPic.

Provided on the resource zip file is a simple web server and on the example implementations, the web server is invokes as a continuous loop. The loop can be broken by any byte coming in via UART 2.

The server needs to be listening all of the time, this can be accomplished by a simple loop. The buffer implemented on UART 1 will cache up to 800 bytes and so this will accommodate a simple page. Any data that comes in on the correct IP address and port (known as a socket) will be passed onto UART 1. ByPic can then interpret this data.

A web browser request is a specific sequence of text that can be interpreted by ByPic, this is something like "GET /<page or action requested> HTTP/1.1" The web server will process the page before sending it back. There are two distinct operations needed, output and input.

A full explanation of how the web server works is provided on the Bypic website here The index page will take you to the BPS12 or BV503 specific pages.

External Sites

It is possible to access external sites as well providing that the Wi-Fi module is connected to of course, to the internet. The 'netutils.bas' file contains information on how to do this.

The technique is to change the mode from server to client, this can be done with the connectIP() function. There is a function that is called getDT() that will get the date and time. A connection is made as a client to Google and a header request is made to their web service. This in turn returns a head that contains the current date and time.

At some later date this could request data from a 'proper' time service but as most web servers, in their head contain the current date and time there seems little point.

Obtaining the IP address of a web site is more difficult. Currently the ping command of the Wi-Fi module is used as there does not appear to be a host or dig command on the wi-fi module that would do the job. This can be problematic as sometimes an IPV6 address is returned and the current firmware of the Wi-Fi module cannot handle that.

Again, it would be quite possible to interrogate a DNS service directly but some work would be required.

Starting from Scratch / How it Works

The ByPic firmware can be upgraded from time to time and also you may want to change the way the ‘core’ files work. By default when the SD Card is inserted into the BP2, the core files are downloaded into the BP2 Flash, this effectively makes the BP2 ‘purposed’ for this job – Wi-Fi link making lots of functions available for this purpose.

The files are only downloaded once, if they exist already in the Flash they are not downloaded again so if a function is changed or a function added to say file netutils.bas then this will not be reflected simply by placing it on the SD Card. To get the functions into Flash, the easiest way is to clear the all of the Flash and the ‘main.bas’ will take care of downloading all of the files again into flash. Although there are quire a few this only takes a few seconds.

  1. Remove the SD Card
  2. type flclear(0)
  3. Optionally upgrade ByPic if there is a new version, check www.bypic.co.uk
  4. Put the new files onto the SD Card
  5. Insert the SD card and reset

NOTES: fclear(0) removes all of the saved function from flash (flclear(1) removes only the last saved set of functions). The new files can be written to the SD Card using Windows. When the card is inserted and reset, the files are automatically loaded again.

To understand what is happening; when ByPic starts it will look for a file on the SD Card called ‘main.bas’ The actual file is here: It will run the function called main().

(main0.bas is now called loader.bas)

The function lookup() will return the address of the function of constant found in flash. If it returns 0 then it does not exist and so it is loaded into ram with flload() and then it is saved to flash with flsave(). By specifying a function or constant in flasve(), as above it will only save the functions or constants AFTER the one specified. Because this program ‘main.bas’ is also in ram ,we do not want to save this as well, hence specifying “STARTP” in flsave.

If you take a look inside startup.bas then the first item is a constant called “STARTUP” this is simply there so that main.bas can use it.

The file ‘main0.bas’ (now loader.bas) does exactly the same job

Developing

Development of software is a process of writing functions. The best way to so this is to have a USB to serial device connected to the UART2 connector, however if a socket has been established then that can also be used.

By default the web server is running, this can be stopped by pressing any key either with a USB to serial converter connected or via a network socket. On breaking out of the web server loop, functions that have been loaded into Flash can be found by typing help.

<< pic breaking out of the server loop >>

Breaking out of the server loop, to run the server again type 'dos'

A file is uploaded to RAM with the .tl command (BvSerial), functions can then be tested in ram before committing to flash. There is no requirement for functions to be committed to flash and can reside on the SD card if required. Main1.bas is an example of this, it is never saved to flash but simply runs from RAM.

For convenience there is also .upf (upload file) command that will transfer a file form the host to the SD Card, this will save having to physically remove the card from the device, also when used remotely files can be uploaded to the SD Card. (currently there is a bug in BvSerial that causes BvSerial to crash when used more than once, press enter between .upf to mitigate it)

Web Server

There is now a standard web server (currently webserver_f.bas) that has been developed so that ByPic functions can be defined inside a html file. This should work for most purposes with some limitations.

The full explanation is on this site

By defualt the server is already installed onto Flash and can be invoked by typing dos. The actual server is called http_server() and can be called in any program loop,or even using an interrupt.

    while comkey?(2) = 0
        // wait for full line
        if bpos(CPORT,0,"\r") > 0 then            
            http_server()
        endif
        wait(100)
    wend

(A watchdog has now been added to this loop. This helps the server keep running even when a particularly bad request is made that causes it to crash. When breaking out of the loop using the USB to Serial, the watchdog is switched off.)

The above is the 'dos' loop; obviously other functions can be placed in the loop. Given the leisurely pace of a browser the http_server() only needs to be called every half second or so.

The server is reasonably complex and this arises from the fact that a web browser is not ideal for sending and receiving real world information and so must be manipulated into doing so. A browser is however on every conceivable IT device so it is well worth the effort.

For more interactive sessions then an 'app' would be more appropriate, all 'apps' can open a socket and talk via that which is much quicker. For windows this can be done using Python or VB and for a Phone I would recommend Basic for Android (B4A) or learning Java.

Further

There is a great potential in this device and only the surface has been revealed with the code provided. Microcontrollers are excellent for:

I2C
SPI
Analogue to digital conversion
Setting and detecting digital values
Timing
Interrupts and input capture

To name a few. Excellent control can be provided by the microcontroller and user interface along with the power that is available that can be provided by the host. Setting up a complex template for example, e.g a green house controller can be adequately controlled with a microcontroller but entering the differing times, dates, on / off, heating requirements could be easily handled on a web browser and then downloaded as a set of numbers. This would otherwise require a clever design with lots of multi function buttons.

There is of course the opportunity to enter this information from say a tablet device that is not fixed to say the inside corner of the greenhouse.

The marriage between a microcontroller with its own operating system and the Wi-Fi module for wider communication is ideal in that the microcontroller is designed for GPIO and is easy to program for that purpose whereas the Wi-Fi gives access to much better user interfaces and the possibility of very remote control.

 

Appendix 2 Troubleshooting

Golden rule

Are you on the same network!!! only devices on the same network address can connect. For example:

192.168.11.any can connect to 192.168.11.any

192.168.16.any cannot connect to 192.168.11.any

** The first three digits MUST match **

Wi-Fi Module

When the Wi-Fi module is operating correctly the red LED should be on and steady, the green led next to that should be on and steady and the green LED furthest away from the red LED should be flashing slowly.

NOTE: The Wi-Fi module does run quite warm, that is normal.

UART 2

BV503: This is the main serial connection to ByPic and ii is provided at [6] (see Green Path). If a Wi-Fi connection cannot be successfully established then this will give access to some useful functions that can be used for diagnosis. Any USB to serial interface will do. Connect TX on the USB to serial to RX on the connector and RX on the USB to serial to TX on the connector and also connect ground, so only three wires are required.

BPS12: This is the normal serial connection to the BP2, it is quite likely that this has already been established, however there is still useful information below.

Use BvSerial and set to the given COM port (given by your operating system) and set the Baud rate to 115200 (.baud 115200) - BvSerial commands start with a dot. Pressing return should reveal a yellow ok, if not recycle the power and check the connections.

This is typically what to expect with the SD card removed. If the SD card is inserted and reset pressed the logging system will show you what's going on.

This is unusually perfect, there may be some errors on your system. Some functions that are useful and can be simply typed directly into ByPic:

init() use this from time to time, and error can cause the COM port to disconnect.

prinfCfg("default.cfg") Shows the current configuration against the default.cfg file. This can be checked against the actual config file.

Mode(1) (note upper case M) this should return 1 or 4, if not use init(). In this mode commands to the Wi-Fi module can be entered e.g

print cmd$("net_ip")

The commands are in the HKL-RM04 data sheet, they are entered without the leading at+ as shown above.

connected() When the wi-fi has joined a network this will return 1

help() Will list the help functions that can be used to see all of the installed functions. To update this with your own functions see the help system.

Alternative Configuration

It is likely that most problems will be due to the wi-fi configuration. There are three ways of configuring the wi-fi module.

1) The normal configuration is via the ByPic program and a configuration file on the SD Card. This has the advantage that the configuration is checked against the actual configuration of the wi-fi module and only those parts that need updating will be updated. The file containing the updater is on bv503.cfg and is called at start up by main1.bas using this line 'updateCfg("default.cfg")'

2) The module can be configured through a browser, the address is the same as the configured address but the port is always 80. So for example if the address is 192.168.16.220, then just putting this address into a browser will bring up the configuration details.

3) It could be that for some reason no access is possible through a browser of from the ByPic system. In this case there is a third option. The light blue path and connector [7] as described in the BV503 hardware section will give direct access to the wi-fi module. Connect a USB to serial converter to this interface and use the config-tool on the zip file. The Baud rate for this is normally 115200. This will allow configuration of the wi-fi module without regard to any other hardware.

BPS12: There is no dedicated connector for this but can be done by using the S-LINK pins as these go directly to the TX/RX pins on the Wi-Fi module.

Wi-Fi Module Checks

To make it easier to develop code and use for the first time. Some checks may have been left out of the main1.bas. This may have the effect that the wi-fi module may not initialise correctly and thus there will be no wi-fi connection to the external browser. For a 'final' working system this is not desirable and so there are checks that can be put in place to mitigate this.

    // check that the module has booted up by trying to set mode. At first
    // switching this can take up to 30 seconds
    for j = 1 to 12
        if Mode(1) <> 0 then
            break
        else
            syslog("main1",format$("Waiting for wi-fi module <%d>",j))
        endif
    next

The module is much slower than ByPic and so the code above will wait until the module has booted up.

    // check configuration against the default, if the defailt.cfg file has
    // changes then the wi-fi module will be updated
    if finfo("default.cfg",a$) = 0 then // it exists
        updateCfg("default.cfg")
    endif

It is a good idea to see if the config has been updated but only AFTER the module has booted.

    // this is where the wi-fi modules connects to the infrastructure - or not
    // connect can take about 30 seconds if an update has taken place
    for j = 1 to 15
        syslog("main1",format$("Waiting for wifi connect <%d>",j))
        ledCon(1)
        if connected() = 1 then
            break
        endif
        wait(100)
        ledCon(0)
    next

The last thing to do is to check that the module is connected.