Messages posted by: stevech

RFM69, which RF band? 433 or 868/915?

I found that Epson makes these type of crystals with your choice of 3 different built-in loading capacitors.
The website photos look similar to the ones on the miniwireless board - the MC146 series.
So I think we can assume that the crystals have the correct capacitors, internally.

https://www.schukat.com/schukat/schukat_cms_en.nsf/index/CMSDF15D356B046D53BC1256D550038A9E0?OpenDocument&wg=D9035&refDoc=CMS1F513C0F64AFF71BC125708900365538

I just hooked up my 'scope to pin 1 on the RTC chip after running the demo program.
'Scope shows a nice sine wave at the correct frequency. That crystal may have built-in capacitors.

I'll run test software to see if I too get the wrong elapsed time.

betgear wrote:Hi Steve,

You've evaded mine and sensorhub's question

When are the low power boards going to be available?

Cheers

Glen.

I'm sorry but you misunderstood my posting. I'm not an employee of Anarduino so I don't know!

I can comment on the tangent, that I had a project that used exotic-chemistry (http://www.tadiranbat.com/) big D cell batteries. Lot of AH capacity, but high internal resistance. So we used supercaps to provide the burst current capacity and the batteries recharged the supercaps (in series). Overall had to run for a year. Burst power consumption was like 100mA as a recall, for a fraction of a second.

There were regulatory/safety issues in air-shipping these, and high capacity Lithium-ion.

Thank you.

I wanted Rick (Mr. Anarduino) to have a go first. That began yesterday - and when has time. Hopefully a couple of days.

The beta version is compiled for RFM69. What others should I strive for in a beta phase? I have only RFM69 mini-wireless boards.

Steve

New beta software for use with RadioHead

PacketPorts IP-like ports for messaging on small-packet networks
and
DXRP (Data Exchange with Remote Reprogramming)

Video demo
http://youtu.be/mQ2CvBVZ_mU

PDF of the "how" - not detailed in the video
https://childresss.opendrive.com/files?90053648_bcgJI

Today I ran the host software on a 3rd platform: Raspberry Pi. (same arrangement as in the video, linked above).
This is the Python coded graphical user interface application plus the Python RadioHead protocol for the link from the computer to the gateway radio to the wireless network.
This makes the computer a member of the wireless network with a network address.
And the Python GUI application supports sending new program code to any network node, including the gateway, to store in SPI flash, then install it in the AVR program memory. On remotely commanded or other reboot cause, the network node that got the new code will then copy it to AVR program memory and run that new code from now on.

So now I've run this on these computers, with three network nodes and the sniffer:

Windows 7/64 bit

Linux Mint 64 bit

Raspberry Pi

All with the app and RadioHead stack in Python 2.

network
Two mini-wireless AVR boards as nodes and one as a sniffer, and one Teensy 3 as a node. All with RadioHead.

The computer and the network nodes have application messaging to do transfers, pings, telemetry reporting, etc. And coexist with an application that uses the same radio and stack/protocol for its own needs.

Hello... regarding the above work I've been doing
The computer part of this was developed on Windows 7 using Python for the GUI and the RadioHead protocols coded in Python for portability among operating systems.
I just brought that up under Linux (Mint). Not hard - that was the goal! Portability.
I'd like to try it on a Mac but I don't own one.

demo video
https://vimeo.com/103387066?utm_source=email&utm_medium=clip-transcode_complete-finished-20120100&utm_campaign=7701&email_id=Y2xpcF90cmFuc2NvZGVkfGJiZDUxMjNjNmJhZjUyYjQzNjQ4MWVmMzY3MGNhM2VjMjA2fDI2ODYzODM1fDE0MDc5NzgyMTZ8NzcwMQ%3D%3D

Steve

sensorhub wrote:Hello Steve,
great video and very impressive demo of your software.

I'm looking forward to when you release it. Do you also support transfer to nodes that only wake up periodically? I ask because all my nodes (except gateway) will go into sleep mode after transmitting data.

thanks for sharing

The node would have to send a mesage every nth wakeup to the host computer to ask if there are any pending activities, one of which might be "new download (program code or other data) is available".
At the moment, automating all this with no operator at the computer isn't in work because that's very application specific. But the messaging protocols are there and some automation on the computer could be implemented.

Or, in a past project, I used a method where the nodes don't transmit a poll as above. They're passive and this is needed for some wireless regulatory regions of the world - especially for mobile/vehicular nodes. I had the gateway broadcast to all in range nodes a "message is waiting", which is a list of node IDs for whom a message is being held. The nodes wakeup long enough to hear the broadcast and if their ID is in the list, they transmit a message to start a transfer. The usual challenge is how to synchronize the node's wakeup so it will "catch" the message waiting broadcast. I did solve that need on a prior project but it is quite dependent on the battery life conservation strategy used in varying applications. I did put in each broadcast a code to say how long until the next broadcast to help nodes synchronize their sleep times. This sort of mechanism is used in time synchronized mesh and star networks, though with more precision than we need here since a receiver turn-on for x amount of time but quite infrequently (say, n broadcast interval times), is simpler.

Another thing I've thought of is for the gateway to receive from the computer various firmware updates or other bulk data, and store it in the 16MB flash board on the Anarduino MW. Tag the data as to which nodes should get the data. Then the computer isn't involved. The nodes and the gateway could do the transfer later in time.

And vice-versa, for data collection done by a node needing to go to the computer, either directly or by store-and-forward at the gateway.

The gateway could have an ethernet interface so any credentialed computer on the LAN or Internet could access the gateway and thus the network. And/or the "comptuer" could be a SBC like the Raspberry Pi or Beaglebone Black.

Lots of use cases.

This too....

I made a demo video... Introduced as a quick demo. Well, the video is 15 minutes long.
A version is on vimeo.com at this link:

https://vimeo.com/103387066?utm_source=email&utm_medium=clip-transcode_complete-finished-20120100&utm_campaign=7701&email_id=Y2xpcF90cmFuc2NvZGVkfGJiZDUxMjNjNmJhZjUyYjQzNjQ4MWVmMzY3MGNhM2VjMjA2fDI2ODYzODM1fDE0MDc5NzgyMTZ8NzcwMQ%3D%3D

Suggest use of full screen mode to see detail and print.

Steve

sensorhub wrote:I would have preferred a more definite reset switch over the existing tactile reset switch. I'm never sure if I have pressed the tactile switch enough and usually have to rely on the serial output of the module to let me know that it has been depressed. It's a small point to mention over an otherwise great product.

This silly 7 port USB hub with power switch per port was one of the best purchases I've made lately.
During development, I just toggle the switch for a certain port to get a reboot. Easy button.

http://www.ebay.com/itm/like/190782584467?lpid=82

I have a lot of this working.. but not done.
Am able to send from PC via gateway to a selected network node, store in SPI flash, remote reboot, the the special bootloader reprograms AVR flash.

This is the essence. Working now on ways to have several programs stored in SPI flash and select which one to program and run.

Please skim this post
http://forum.anarduino.com/posts/list/0/13.page#23

steve

The concept I've been implementing is to use a standardized network to send any sort of data, one type being a file containing new program code for remotely located device that is networked as a node.
This leads the means to:
Send a program code update to an addressed "node" within a network. From a PC/Mac/Linux computer.
Send a large file that is not a programming update to any node. This might be configuration data or other app-specific data.
Conversely, receive a large data set from a network node and store it on the PC/Mac/Linux computer. This might be data acquisition logged data/GPS, etc.

The first capability will be specific to the Anarduino MiniWireless boards. These can be ordered with a variety of data radios for 433/868/915MHz and 2.4GHz bands. Some of these radios can operate in Ham bands with fewer usage and power restrictions.

The networking will use the open source RadioHead protocols. The RadioHead library is Arduino and Teensyduino compatible. The lowest level in a RadioHead stack is a driver for the radio module or a wired data link such as UART/RS232/USB. The layers on up from this are agnostic as to what transmission media (wired/wireless), much as is TCP/IP.

Each network node (e.g., a MiniWireless board) has a unique 8 bit network address of your choice, perhaps stored in EEPROM by your app.
The RadioHead protocol choices you make include a driver for the chosen radio board and your selection of a network type (topology), including:
1. Datagram packets with error detection and error correction duty falling upon the application. Much like IP's UDP. Jargon: Unreliable Datagrams.
2. Datagrams with error correction via ACK messages, with correction done automatically within the protocol stack.
3. A routed network where each node is given a static routing table of neighbor nodes. The protocol stack uses the static routes to get data from source to destination.
4. An Ad-hoc Mesh network, where nodes dynamically discover their neighbor nodes and collectively, datagrams move in hops / relays to/from the source and destination nodes. This applies mostly when there is no RF connectivity permitting one-hop (no relay) packet / datagram flows.
5. A wired network, as simple as a UART/RS232/USB link from a network node/MiniWireless board to a PC/Mac/Linux computer's serial / USB port.
6. A multi-drop wired network with several network nodes on the wired media, e.g., RS-485 or CAN
In addition to node addressing, from/to, there is a broadcast address to send the same packet to all nodes in the network.

As discussed below, the RadioHead stack for the above is the same as an application would use to exchange data with other nodes or a bridging gateway to a computer or connectivity to a LAN and onward as needed.

Here's the status
The MiniWireless board is the first target because it has a large flash memory chip in which to store received files of AVR program code and other data, as above. The flash chip differs from that of the LowPower Wireless boards. The impetus for this project was this difference. But moreover, the impetus was to use a robust protocol stack so that the application can also use the same stack for its communications needs.

The receiving nodes use a send/receive protocol to move files. This is now the RadioHead Datagram addressed packet protocol with CRC16 error checking at the link layer and at the file level.
The AVR m328P code for this is doing basic receiving now.
A new bootloader for the mega328P as used on the MiniWireless boards is running. It is compatible with AVRdude and Atmel Studio 6 (STK500) in using the Serial UART at 57600Baud.
And the new bootloader detects if a new program code file was previously downloaded and stored in the flash chip. If so, the AVR's flash is reprogrammed by the bootloader.
This new bootloader fits in 1KB and and written in C.

An application library for use by your application can download and store into the bulk flash chip, a new program code or other type of data.
The RadioHead protocols needed for the above have been integrated.

On the PC/Mac/Linux host that does file "pushes" out to network nodes...
The RadioHead stack for datagrams has been implemented in Python for PC/Mac/Linux. The Datagrams move on the serial/USB-serial link from the computer to a "gateway" MiniWireless board.
To push out a file, you install/run the Python (v2.7) program. A graphical user interface enables you to choose what file to send to which network node. And you state if the file is program code or generic data.
If the file is a normal .hex file (from Arduino or Studio 6 or Visual Micro), it is decoded and sent via the Datagram protocol from the host computer to the gateway board and then across the wired/wireless network to the chosen network node. The binary transfer of the .hex file is 1/3 the size of sending the .hex file. It also simplifies the bootloader on the AVR.

More concisely
Install new bootloader on all your boards, using some sort of ISP. Try it in normal UART bootload usage.
Choose a MiniWireless to be a gateway - between the network and the PC/Mac/Linux computer via serial.
Install the gateway's application code.
On each network node board, add the downloader library to your application code base. It will talk to the gateway to download files and store in the bulk flash chip.

This is what phase 1 of this project is to be.
The PC/Mac/Linux GUI-based Python app is working. The Python version of the RadioHead serial port Datagram is working.
The gateway application is working to download.
Code to read/write the bulk flash chip.. tested. Is in the bootloader. Same code needs to go in the downloader library for all nodes. And downloader in gateway so it can do store-and-forward).
The gateway can also bridge packets from the network to your application on the PC/Mac/Linux box - say some PC that exchanges data/commands with network nodes in one of the network topology types as above).

This has been in work for many weeks. It's not intended to be a quick hack limited to just over the air programming without a real network. Hopefully, there's a call for such as people build systems with several or many wireless/wired nodes.

EDIT:
Here is a short video demo of the GUI running in Python on a PC doing a .hex file transfer.
The Python code also has the Python versions I've done, of RH_Serial, RHGenericDriver, RHDatagram. The AVR side has RH_serial for the gateway to PC, and will bridge to RH for the wireless side.

https://vimeo.com/100167413

steve