Linkbus Messaging

[NZ0I]

I mentioned in a previous post that the processors USARTs will be used for serial communication (Linkbus) between the Control Head and the Digital Interface boards. The USARTs will also be used to allow both of those boards to be interfaced to a computer through a serial port (USB).

In addition to supporting bootloading of software updates, USART support will open the possibility of using the Digital Interface board directly by a computer. The Digital Interface board all by itself (without a Control Head or Receiver board) could serve as a platform for controlling the Si5351 clock chip, and other components it contains, via computer. That would make the small Digital Interface board useful as a 3-channel HF-to-VHF signal generator simply by connecting it to a PC, Mac or Linux machine.

At the moment I am defining a simple-but-flexible messaging protocol that will allow the Control Head to communicate with the Digital Interface, so that the Control Head will function just like a fully integrated keypad, rotary dial, and LCD display for operating the radio. But this same messaging protocol should also serve to allow a computer to wield the same control via a USB connection. So I'm trying to be careful in the protocol definition to avoid limiting the ability of a user to control the board, or making it too complex for someone to type in the commands from a computer.

Here is a sample of what the command protocol is looking like at the moment. The command to set the Si5351 CLK0 settings to 145.52MHz, enabled, high drive setting, looks like this:

$SC0,145520000,1,1;

where:

 $ = indicates message start

 SC0 = the CLK0 settings message ID

 145520000 = frequency in Hz (field 1)

 1 = enable the output (field 2)

 2 = set the pin drive to high (field 3)

 ; = end-of-command terminator

Fields can be left blank to make no change; so to set the frequency (and leave the other pin settings unchanged) the command becomes

$SC0,145520000,,;

  or equivalently

$SC0,145520000; 

The Control Head would query the current Si5351 CLK0 settings by submitting a query message as follows:

$SC0?

where:

 $ = indicates message start

 SC0 = the CLK0 settings message ID

 ? = end-of-query terminator

To which the response from the Digital Interface would look like this:

!SC0,145520000,1,1;

where:

 ! = indicates response message start (i.e., this message contains data, not a command)

It will also be possible to request that the Digital Interface automatically report (broadcast) changes in certain things like signal strength, battery level, gain setting, etc. The commands ordering the Digital Interface to report changes in signal strength, and to stop such reporting, are:

$S?     <- Start RSSI broadcasts

$S;      <- Stop RSSI broadcasts

A broadcast from the Digital Interface indicating the received signal strength changed to 30% of full scale would look like this:

!S,30;

It will be easy enough to create new commands, queries and responses. But as time goes by, and development continues, it will become more labor intensive to make fundamental changes to the protocol itself. So if anyone has any suggestions, questions, or concerns, now would be a great time to discuss Linkbus messaging on this thread.

[Gerald Boyd]

A good start. Look s like I need to get a USB to serial chip. Is there one you are using? I think spark fun may have one.

Also I would be willing to help with looking over the command specification document.

I think this adds lots of flexibility. Using the interface to re purpose as  signal generator is a good example. 

A java based GUI could be developed by a user that could run on a PC, MAC or Linux system and could be customized as a user interface for the application to translate user inputs to low level commands and responses back to GUI displays.

Jerry

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/a2e80475-b68b-495b-9c56-9c266daf034d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charles Scharlau]

I'm thinking we'll want to use the FTDI chip, like the one AdaFruit puts in this cable that they sell: https://www.adafruit.com/products/70. SparkFun may have a similar product. DigiKey sells the chip for $4.50: https://www.digikey.com/products/en?keywords=768-1007-1-ND

We could add the FTDI chip to each board, but that would add cost. But to use the FTDI adapter cable we'll need to add a connector for it to connect to. The simplest connector might be a 6-pin SIP header to mate directly with the AdaFruit cable. But we couldn't very well bring a row of pins outside the receiver chassis, so I'm thinking we'll want to use a different connector. But a quality 6-conductor connector could easily cost more than the FTDI chip.

A slick way to provide an external connector for USB connection would be to use the very same micro-USB connector that we already have on the boards for charging the LiPo battery. Then you could simply use a standard USB-to-MicroUSB adapter cable to connect with the computer (and charge the receiver at the same time). But that would mean putting the FTDI chip internal to the receiver, and adding that extra expense.

I don't have an ideal solution to this, and I'm open to suggestions. But I'm leaning toward adding a board footprint for the FTDI chip that can be optionally populated. We could also add a board footprint for a 6-pin header, for those who would prefer the AdaFruit adapter cable. Making parts optional allows builders to make the choice themselves, but adding extra footprints has a cost of its own - increased board size, and increased complexity for the builder.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development-platform+unsub...@googlegroups.com.

[Patrick R. Sears]

The protocol seems pretty simple and easy to work with.  I haven't worked with USART but, from a user point of view typing things into a computer, I see no problems.

But I need a bit of help to keep up with changes...

The control head is on the receiver all the time?  It's the same thing as the "UI module"?   While in the field, the user input is all done via the rotary encoder (RV301) and the four push buttons (SW301, ... SW304)?  U301 handles all user input/output and U103 handles the Si5351.  So when the computer is plugged in, USART will go to U301?  Or both and U103 and U301 and they will talk to each other with USART also?

Sorry, I'm getting a bit confused.


Best,
Patrick

--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.

[Patrick R. Sears]

I use the Adafruit FTDI cable to program their "Pro Trinket" in the course timing system.   From the user point of view, using usb on the Pro Trinket does not allow the use of a serial monitor for debugging.  With the FTDI cable, the user needs to buy that extra cable, but then the serial monitor works, which is super super handy.

I don't have the background necessary to understand the choices they made.  But someone better qualified may find it useful to take a look.  The Pro Trinket also uses an ATmega328 and the board size was partially optimized for small size.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/CAK-GiwZauzX2n78VoAONWsmJ9mJck-g4kz51sKCf0fahiJypRw%40mail.gmail.com.

[Charles Scharlau]

The project has undergone a lot of changes in recent months, and it would be amazing if there wasn't confusion. To avoid adding more confusion, I won't mention the original concepts. The names we used are still present in schematics, where they still have meaning for describing the KiCad schematic sheets. The text below just describes the project as it stands right now. (I think some drawings would help, but I'll need some time to get artsy.)

The Receiver Development Platform has three different PCBs: The Control Head, the Digital Interface, and the Receiver.

RECEIVER

The Receiver contains all of the analog circuitry for the dual-band ARDF receiver, but lacks the clocks, and user-interface support to make it usable. So the Receiver is dependent on the other two PCBs, and has no processor of its own. It can be made to work by adding any source of external power, clocks, and audio amplifier - such as Jerry's test rig he created for testing. But it is designed to fit pin-in-socket with the Digital Interface board.

The other two boards, the Control Head and the Digital Interface, are more interesting, partly because they each have their own ATmega328P processor. They can be purposed for different things, and they can be used individually or together. They can be connected together permanently, or temporarily through connectors. 

BUILD ALL THREE

If you build a Control Head, a Digital Interface, and a Receiver board, you can wire them all permanently together to create a feature-laden high-performance dual-band ARDF receiver (at least that's the goal). If all goes well, you can put the whole kit-n-kaboodle into a custom-designed 3D-printed chassis, and have something the likes of which has never been seen in ARDF history.

Note: Much of the cost of that high-end ARDF receiver is contained in the Control Head: the LCD, buttons, rotary encoder, switching power supply, and a relatively large PCB to hold everything. The Control Head accounts for a large fraction of the total receiver cost. If you could just get rid of the Control Head you could bring the cost way down.

BUILD JUST CONTROL HEAD

Suppose you build just the Control Head. It can be a useful device if you have other devices that can use its 4-button, 1-rotary knob, 2x20 character LCD display UI. It isn't hard to imagine how the Control Head might be useful to program and configure any number of devices that can communicate with it over its serial bus: time registering stations (punch boxes), transmitters, simple receivers, and other devices that have not yet been imagined, could all be used with it. As long as it is OK to disconnect the Control Head from one device, before connecting it to another, you will only need to build (and pay for) one Control Head. That is potentially a huge cost savings if you are maintaining a stable full of transmitters, time registers, and loaner receivers for ARDF practice, for instance.

BUILD JUST DIGITAL INTERFACE

The Digital Interface can serve as a 3-channel HF-VHF signal generator, an audio amplifier, and a real-time clock, and has lots of pins that will let it interface to other boards (including the Receiver board). It can be controlled using a computer, or...

BUILD CONTROL HEAD AND DIGITAL INTERFACE

Building those two devices and wiring them together gives you a stand-alone 3-channel HF-VHF signal generator, an audio amplifier, and a real-time clock. It also has lots of pins that will let it interface to other boards you might design that can be controlled through a 4-button, 1-rotary knob, 2x20 character LCD display UI, and powered by a rechargeable LiOn battery.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development-platform+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/a2e80475-b68b-495b-9c56-9c266daf034d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development-platform+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/8dda57c1-2b26-ed1a-56e6-d351c8749868%40gmail.com.

[Patrick R. Sears]

Thanks Charles.  That was super handy  :  )

[Charles Scharlau]

I probably should have added this combination:

BUILD DIGITAL INTERFACE AND RECEIVER

This combination, plus adding a few blinky LEDs and pushbuttons, can get you an inexpensive dual-band ARDF receiver. It won't have a Control Head, so it is cheaper than the deluxe receiver approach. It will, however, be able to be attached to a detachable Control Head for easy programming and configuration. In the field, it would have a much more rudimentary UI that would provide simple and intuitive control over basic functions (changing from one band to the other, for instance), but more complex operations would be cumbersome without attaching a Control Head or PC. The less-expensive receivers will, hopefully, be more affordable as loaner receivers... especially if they can be readily installed into inexpensive off-the-shelf chassis boxes, or even PVC pipe.

[Charles Scharlau]

I'm not familiar with the Pro Trinket at AdaFruit. I visited their page: https://www.adafruit.com/products/2000. They say that you can bootload new code using USB or FTDI. It reads like there is nothing else you can do using USB, other than loading new code.

Offering USB for bootloading sounds like a good idea, so that those who only want to install new firmware can just use a standard USB-to-microUSB cable, like what comes with most cell phones. Those who want to configure their receivers or transmitters using a PC would need to buy an FTDI cable. But I don't like having to open up the case in order to access the 6-pin FTDI header.

One other thing that concerns me is their mention "The bootloader on the Pro Trinket use 4KB of FLASH". I thought that only 2kB is needed normally - I wonder if that is due to the "Optiboot" support for both USB and FTDI.

I guess I still lean toward having the option of adding FTDI internally to the receivers and transmitters. But I'll have to look into how AdaFruit provides the USB bootload support. Maybe that can also be supported even if one chooses to leave out the optional FTDI chip, but that might mean giving up 2k of flash.

To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/CAK-GiwZauzX2n78VoAONWsmJ9mJck-g4kz51sKCf0fahiJypRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development-platform+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/8804c8ea-0602-fb8b-a322-25e63d79284f%40gmail.com.

[Patrick R Sears]

The Pro Trinket with which I have experience is actually product ID 2010.  It's the 3.3V, 12 MHz version.  But I think that everything else is almost exactly the same.

About the optiboot, I'm not sure.  What I do know is that they had to develop a new IDE to talk to their Pro Trinket.  Since I don't need as precise timing for my system, I use the arduino IDE instead of avr-c.  But I can't use the regular IDE.  I had to download their modified version.  I'm not sure if that's useful information.  But it is obvious that their system requires a lot of custom software to make it work.  Maybe to make it easy for people used to arduino code directly.  Or maybe to get both the usb and ftdi to work.  Not sure.

For our system, I like the micro-USB connector to the outside.  But I don't know enough about implementing either USB or FTDI to make an intelligent comment.

To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/CAK-GiwZ86gSgR8NQ4U3fr90yF%3DTqsjXKO7UeW1fL9t-vH-Ed%2Bg%40mail.gmail.com.