# DV Dongle - AMBE USB Device **URL:** \ **Category:** GNU Radio\ **Created:** [March 18, 2008, 6:54pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284 "2008-03-18T18:54:16Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 18, 2008, 6:54pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/1 "2008-03-18T18:54:16Z")
Hello, One of the “problems” with DStar and some other digital voice systems is the Patent and other IP considerations. DStar uses the AMBE codec which is owned by DVSI. Icom uses a DVSI AMBE2020 chip in their DStar products. One possible solution is to buy hardware that puts the Patent and IP into a chip. This increases the cost of the hardware and you need to interface it to the PC. Some chip makers do not make chip information available, but DVSI does. The USER Manual is very informative. [http://www.dvsinc.com/products/a2000.htm](http://www.dvsinc.com/products/a2000.htm) A group was able to produce a USB Device that interfaces the AMBE2000 chip to the PC. The icing on the cake is it is an open source project. The API appears similar to the RF Space SDR products. [http://www.moetronix.com/dvdongle/](http://www.moetronix.com/dvdongle/) The DV Dongle is now in production and even has a website, [http://www.dvdongle.com/DV\_Dongle/Home.html](http://www.dvdongle.com/DV_Dongle/Home.html) So I ordered one for $200 from HRO and hope to get it in a few days. It should be possible to add support for it in GNURadio. I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter and see if the device can decode P25 as well. This may be a general IMBE and AMBE codec. 73 Eric ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 5:11am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/2 "2008-03-19T05:11:27Z")
Eric A. Cottrell wrote: > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter and see > if the device can decode P25 as well. This may be a general IMBE and > AMBE codec. I hope so. I looked at this a while back. What concerned me most was the AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. Compare the docs to another DVSI product - the VC55 - to see what I mean. ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 6:38am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/3 "2008-03-19T06:38:48Z")
Rick P. wrote: > to see what I mean. Hello, Looking over the docs the VC55 is a P25 only AMBE+ 2 CODEC that only supports full rate and the proposed (maybe part of standard now) half rate. What is good is the mention that the improvements are still compatible with the P25 vocoder standard. The AMBE + 2 part sounds like further improvements to the CODEC over the AMBE2000. The future AMBE3000 will implement AMBE + 2 and it appears compatible with the AMBE2000 and AMBE1000. The AMBE2000 is more flexible in the data rates and when I look at the rate tables on page 29 I see the P25 rate listed with the correct voice and FEC data rates. You can do the same rate in AMBE or AMBE+. So one task will be to figure out how to configure the chip so it will decode P25. 73 Eric ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 4:40pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/4 "2008-03-19T16:40:08Z")
----- Start Original Message ----- Sent: Wed, 19 Mar 2008 07:02:08 -0600 From: Jeff B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Rick P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > If you’re looking at low bitrate codecs for GNU radio, why use a hardware (dongle) > dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps, > and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG > 4591). Common applications are HF radio and L band satellite apps where bandwidth is > very limited. ----- End Original Message ----- Hello, That would be a good idea if I was doing digital voice from scratch but I am trying to decode IMBE and AMBE used in APCO P25 and a number of other systems like MA/COM ProVoice and some Inmarsat stuff. MELPe may be a great solution to get Ham Digital Voice away from IMBE and AMBE. It may be difficult to do in the case of VHF/UHF with older P25 radios being available surplus. IP issues can be a minefield as the Rembrandt Technologies suit about their ATSC patents shows. I heard that HDTV Grand Alliance made the mistake of not having a formal patent pool and there was an informal agreement. Rembrandt got the technology patents from AT&T which was part of the HDTV Grand Alliance and decided to play hardball and recover the costs of buying the patents plus make a profit. Having dealt with companies that only release information under NDA, I can appreciate that DVSI has their information available so a device like DV Dongle can be made. It is not a good clean open source solution but is like the MadWifi driver. I would like to play with ALE and STANAG protocols someday. Thanks for the information and I will look up more information on it. 73 Eric ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 5:03pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/5 "2008-03-19T17:03:56Z")
On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff B. wrote: > If you’re looking at low bitrate codecs for GNU radio, why use a hardware (dongle) > dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps, > and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG > 4591). Common applications are HF radio and L band satellite apps where bandwidth is > very limited. > > -Jeff Unless something has changed, MELP is also encumbered. How about a free codec, such as speex? [http://www.speex.org/](http://www.speex.org/) Eric ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 5:42pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/6 "2008-03-19T17:42:27Z")
speex is nice. I’ve used it as well as the AMBE2000/2020. I wasn’t in love with the AMBE. We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 pair of DSPs work in our application. Specs were light and idiosyncrasies were numerous. j0j ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 5:56pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/7 "2008-03-19T17:56:02Z")
Jared- > speex is nice. I’ve used it as well as the AMBE2000/2020. I wasn’t in love with > the AMBE. We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 pair > of DSPs work in our application. Specs were light and idiosyncrasies were > numerous. What was the lowest bitrate you used with Speex? My understanding is that Speex’s PESQ scores are below 3 for anything below 3000 bps. -Jeff ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 19, 2008, 1:03pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/8 "2008-03-19T13:03:46Z")
Rick- > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter and see > > if the device can decode P25 as well. This may be a general IMBE and > > AMBE codec. > > I hope so. I looked at this a while back. What concerned me most was the > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > Compare the docs to another DVSI product - the VC55 - to see what I mean. If you’re looking at low bitrate codecs for GNU radio, why use a hardware (dongle) dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps, and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG 4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. -Jeff ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 20, 2008, 4:31am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/9 "2008-03-20T04:31:13Z")
On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick P. wrote: > Jeff B. wrote: > > > If you’re looking at low bitrate codecs for GNU radio, why use a > > hardware (dongle)dependent solution? You might look at MELPe, which > > provides 600, 1200, and 2400 bps,and can be implemented as a software > > solution. MELPe is a US/NATO standard (STANAG4591). Common > > applications are HF radio and L band satellite apps where bandwidth is > > very limited. > > My interest is what is actually being used - which in the case of public > > safety communications is the P25 variant of IMBE. FWIW, a closed source > > PC hosted IMBE vocoder exists now. Is this a DVSI licensed and publically available closed source module or something “unofficial” or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues… and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don’t see this as in their interest). – Dave Emery N1PRE/AE, removed\_email\_address@domain.invalid DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten ‘For Rent’ sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn’t and is not to be now either." ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 20, 2008, 1:39am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/10 "2008-03-20T01:39:29Z")
Jeff B. wrote: > If you’re looking at low bitrate codecs for GNU radio, why use a > hardware (dongle)dependent solution? You might look at MELPe, which > provides 600, 1200, and 2400 bps,and can be implemented as a software > solution. MELPe is a US/NATO standard (STANAG4591). Common > applications are HF radio and L band satellite apps where bandwidth is > very limited. > My interest is what is actually being used - which in the case of public > safety communications is the P25 variant of IMBE. FWIW, a closed source > PC hosted IMBE vocoder exists now. ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 20, 2008, 7:17am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/11 "2008-03-20T07:17:44Z")
David I. Emery wrote: > Is this a DVSI licensed and publically available closed source module > or something “unofficial” or not generally available to the world at > large ? It has obviously long been possible to recode some reverse > engineered DSP chip based IMBE implemenation into C++ source code for > Wintel/Unix/BSD use, but this would not be free of license and patent > issues… and could not be made part of an open sourced project or > product without a DVSI deal (and it appears they don’t see this as in > their interest). > Reverse engineering - at least for two common IMBE variants (P25 and > MA/COM’s ProVoice) - isn’t necessary. Both algorithms are published by > DVSI through the TIA. One of WinRadio’s more recent offerings includes a software codec option for P25. It’s a $99 download - probably DRM’d to your radio’s serial number. ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 20, 2008, 1:34pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/12 "2008-03-20T13:34:41Z")
Rick- > DVSI through the TIA. > Are these publications actual C code, along with input/output test > vectors that can > be used to verify bit-exact performance of a software implementation? -Jeff ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 20, 2008, 11:48pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/13 "2008-03-20T23:48:34Z")
Eric- > > > > provides 600, 1200, and 2400 bps,and can be implemented as a software > > > > engineered DSP chip based IMBE implemenation into C++ source code for > > > > is similar to the MadWiFi drivers where there is a closed source HAL > > > > provided by Atheros and the open source part is the interface of the > > > > HAL to the OS. Not the best solution but otherwise there would be > > > > nothing. Have you seen one of the IMBE dongle codec chips up close? Is it a TI DSP, maybe something like a TMS320VC5509, or similar? DVSI typically uses TI DSPs. I’m wondering, because IP rights issues for MELPe go away for 2400 bps rate if a TI chip is used; TI will normally waive royalty fees in that case. Maybe a similar approach could be taken for MELPe, it would be cheap and not tied to a radio receiver or other equipment. Just a dongle for GNU radio. -Jeff ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 20, 2008, 7:25pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/14 "2008-03-20T19:25:51Z")
----- Start Original Message ----- Sent: Wed, 19 Mar 2008 23:29:57 -0400 From: “David I. Emery” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: Rick P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > > PC hosted IMBE vocoder exists now. > > Is this a DVSI licensed and publically available closed source > module or something “unofficial” or not generally available to the world > at large ? It has obviously long been possible to recode some reverse > engineered DSP chip based IMBE implemenation into C++ source code for > Wintel/Unix/BSD use, but this would not be free of license and patent > issues… and could not be made part of an open sourced project or > product without a DVSI deal (and it appears they don’t see this as in > their interest). > Hello, In the case of the DV Dongle they buy the DVSI chips and designed a USB interface to connect to a PC. DVSI gets paid for their work. It is a neat solution for the problem of providing PC and Network support for D-Star. The open source part is the interface to the CODEC chip. It is similar to the MadWiFi drivers where there is a closed source HAL provided by Atheros and the open source part is the interface of the HAL to the OS. Not the best solution but otherwise there would be nothing. DVSI does make a PC solution for their licensees. I have the APCO P25 Voice Module for my WinRadio G305e and it is keyed to the radio serial number. Because the DV Dongle has a published API I was able to see that it should be possible to run the CODEC at different rates. That is one area of exploration I want to do. I also want to see if the AMBE codec can be used on a IMBE stream. I have seen comments online that they are totally different yet I also see comments from the TIA P25 group that the AMBE codec is an improvement over the IMBE codec and it should be implemented by equipment makers. This seems to indicate that the stream format is the same at least at P25 rates. I find that new products of a company tend to be built on past products of the company. Companies tend not to throw out stuff that works if it still works on the new products. So the improvements could be in the quality of the encoding and decoding rather than changes in stream formats. 73 Eric ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 21, 2008, 2:41am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/15 "2008-03-21T02:41:02Z")
Jeff B. wrote: > > > On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick P. wrote: > > > > > > > My interest is what is actually being used - which in the case of public > > > > their interest). > > > > nothing. > > > > -Jeff > > > > Hello, This picture of the prototype shows it is a TI chip. [http://www.moetronix.com/dvdongle/](http://www.moetronix.com/dvdongle/) The problem is it may be a ROM or protected Flash version of the DSP chip. I paid for a AMBE codec so I do not want to destroy the internal programming, However this could be used for another project using a TI DSP for a MELPe dongle. The DV Dongle could be a defacto standard for external CODEC interfacing. 73 Eric ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 21, 2008, 7:10am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/16 "2008-03-21T07:10:04Z")
Jeff B. wrote: > Are these publications actual C code, along with input/output test > vectors that can be used to verify bit-exact performance of a software > implementation? > This is not a reference implementation. The documents describe the > algorithm(s) down to the bit level. It is not tied to a specific > programming language or processor. The decision as to how to manipulate > the bits (C, asm, or FPGA) is up to you. Maybe Eric C. can use his new DV-Dongle to publish some test vectors. 🙂 -rick ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 21, 2008, 4:06am UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/17 "2008-03-21T04:06:36Z")
Eric- > This picture of the prototype shows it is a TI chip. > [http://www.moetronix.com/dvdongle/](http://www.moetronix.com/dvdongle/) > > The problem is it may be a ROM or protected Flash version of the DSP > chip. I paid for a AMBE codec so I do not want to destroy the internal > programming, Yes it’s probably a ROM’ed version, but it’s only 100-pin so it’s too small for 54x or 54x device, unless much older. My guess is a member of the C24x series, which has onchip ROM or Flash, low-power enough to live off the USB, and some stern security features. > However this could be used for another project using a TI DSP for a > MELPe dongle. The DV Dongle could be a defacto standard for external > CODEC interfacing. The Moetronix board/DSP could not be used, but a similar design with a TI DSP, USB interface, and Flash EEPROM is simple enough. The problem with making it entirely open would be NSA’s export restrictions on MELPe. -Jeff ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 21, 2008, 10:23pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/18 "2008-03-21T22:23:54Z")
Jeff B. wrote: > All the standardized codecs that I know of, both ones with IP rights > requirements and free ones, provide a reference design, typically > fixed-point C code plus test vectors. I wonder why DVSI has not done > the same. Perhaps the APCO and TIA committees did not require it when the algorithm was published ten years ago. -rick ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 21, 2008, 6:29pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/19 "2008-03-21T18:29:23Z")
Rick > > Are these publications actual C code, along with input/output test > > vectors that can be used to verify bit-exact performance of a software > > implementation? > > This is not a reference implementation. The documents describe the > > algorithm(s) down to the bit level. It is not tied to a specific > > programming language or processor. The decision as to how to manipulate > > the bits (C, asm, or FPGA) is up to you. All the standardized codecs that I know of, both ones with IP rights requirements and free ones, provide a reference design, typically fixed-point C code plus test vectors. I wonder why DVSI has not done the same. -Jeff ---
**Author:** ![Eric\_ASCottrell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/898d66/32.png) [@Eric\_ASCottrell](https://www.ruby-forum.com/u/Eric_ASCottrell)\ **Post date:** [March 21, 2008, 11:52pm UTC](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284/20 "2008-03-21T23:52:48Z")
On Fri, Mar 21, 2008 at 04:23:00PM -0500, Rick P. wrote: > Jeff B. wrote: > > > All the standardized codecs that I know of, both ones with IP rights > > requirements and free ones, provide a reference design, typically > > fixed-point C code plus test vectors. I wonder why DVSI has not done > > the same. > > Perhaps the APCO and TIA committees did not require it when the > algorithm was published ten years ago. I’m sure there was a bit of negotiation to get the best available vocoder technology and still preserve MIT’s and DVSI’s interests. A full reference implementation in C would have been immediately employed by a variety of entities seeking to use the technology without the royalties and control DVSI and MIT wanted - anything published like that would have been impossible to control. And history indicates they made a choice that served their interests well - radio hobby and hacker and far east clone (read “Chinese copy”) use of P25 IMBE on a PC or in unlicensed hardware has not been a major issue for 10 years, though no doubt more than a few versions do exist outside of official DVSI licensees. It is hard to believe this would have been true if the standard came with C source code… regardless of its license status and the formal restrictions on using it. And this has no doubt made it easier to collect revenue from the hefty fees for licenses… if only because at least some major users haven’t been as annoyed by hobby software that scares their law enforcement customers away from P25 + IMBE as they no doubt would have been if unofficial copies of the C from the standard were available and in wide use in PC radio hobby software. It is at least probably true that at least two common VHF/UHF non P25 digital radio systems that currently are not supported by readily purchased scanner would be readily monitorable by the general public if IMBE source was available, even with the potential patent infringement involved - and I am sure this hasn’t escaped notice. – Dave Emery N1PRE/AE, removed\_email\_address@domain.invalid DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten ‘For Rent’ sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn’t and is not to be now either." [Next page](https://www.ruby-forum.com/t/dv-dongle-ambe-usb-device/132284.md?page=2)