Topics

ThumbDV and Buster on OS X


Luke.evans@...
 

I know this isn't the official place to get Buster support per se, but maybe folks here have some clue...

I bought a ThumbDV ages ago (probably a very early rev) and recently got it out to try with Buster on macOS.  
While I can see the serial device appear in /dev when I plug it into my USB port, Buster abjectly refuses to connect to it, saying that it cannot open the serial port.  

I'm using macOS High Sierra.
My Mac is a recent MacBook Pro (consequently I'm using a dongle to present a USB 3 port from the onboard USB-C - but the hardware does seem to be recognized correctly)
I have not installed additional drivers - hence using the default serial driver
I'm logged in as a regular user (though I've also tried launching Buster with sudo - but no difference in behaviour). 

Any clues greatly appreciated!  


Dan Porter (AI2M)
 

I don’t have the USB version but with an older device I believe you need to select the 230400 Baud Rate. With my AMBE server setup after I input the correct info I have to select one of the other tabs and then the Vocoder tab again before I see the connection information appear.

73, Dan (AI2M)

On 4 Jul 2018, at 16:41, Luke.evans@... wrote:

I know this isn't the official place to get Buster support per se, but maybe folks here have some clue...

I bought a ThumbDV ages ago (probably a very early rev) and recently got it out to try with Buster on macOS.  
While I can see the serial device appear in /dev when I plug it into my USB port, Buster abjectly refuses to connect to it, saying that it cannot open the serial port.  

I'm using macOS High Sierra.
My Mac is a recent MacBook Pro (consequently I'm using a dongle to present a USB 3 port from the onboard USB-C - but the hardware does seem to be recognized correctly)
I have not installed additional drivers - hence using the default serial driver
I'm logged in as a regular user (though I've also tried launching Buster with sudo - but no difference in behaviour). 

Any clues greatly appreciated!  


Dan Porter (AI2M)
 

It looks like the changeover date to the higher speed was 13 July 2015 from this page:
http://nwdigitalradio.com/thumbdv-and-dv3000-resource-page/

and you probably have this one: https://nw-digital-radio.groups.io/g/ambe/wiki/AMBE-Devices

— Dan

On 4 Jul 2018, at 17:24, Dan Porter wrote:

I don’t have the USB version but with an older device I believe you need to select the 230400 Baud Rate. With my AMBE server setup after I input the correct info I have to select one of the other tabs and then the Vocoder tab again before I see the connection information appear.

73, Dan (AI2M)

On 4 Jul 2018, at 16:41, Luke.evans@... wrote:

I know this isn't the official place to get Buster support per se, but maybe folks here have some clue...

I bought a ThumbDV ages ago (probably a very early rev) and recently got it out to try with Buster on macOS.  
While I can see the serial device appear in /dev when I plug it into my USB port, Buster abjectly refuses to connect to it, saying that it cannot open the serial port.  

I'm using macOS High Sierra.
My Mac is a recent MacBook Pro (consequently I'm using a dongle to present a USB 3 port from the onboard USB-C - but the hardware does seem to be recognized correctly)
I have not installed additional drivers - hence using the default serial driver
I'm logged in as a regular user (though I've also tried launching Buster with sudo - but no difference in behaviour). 

Any clues greatly appreciated!  


Lou Fisher
 

Good luck I bought the thumbdv about two years ago. Got the new version and it worked great for about two years. Now have similar problems seems about two months ago several just quit working.  I know of at least ten different people with same problem all happening at about same time.  If anyone has any solutions please post we loved our thumbdvs

On Jul 4, 2018, at 4:09 PM, "Luke.evans@..." <Luke.evans@...> wrote:

I know this isn't the official place to get Buster support per se, but maybe folks here have some clue...

I bought a ThumbDV ages ago (probably a very early rev) and recently got it out to try with Buster on macOS.  
While I can see the serial device appear in /dev when I plug it into my USB port, Buster abjectly refuses to connect to it, saying that it cannot open the serial port.  

I'm using macOS High Sierra.
My Mac is a recent MacBook Pro (consequently I'm using a dongle to present a USB 3 port from the onboard USB-C - but the hardware does seem to be recognized correctly)
I have not installed additional drivers - hence using the default serial driver
I'm logged in as a regular user (though I've also tried launching Buster with sudo - but no difference in behaviour). 

Any clues greatly appreciated!  


 

If you are talking about MacOS and Buster -- check https://github.com/mcdermj/buster/issues

On Wed, Jul 4, 2018 at 2:26 PM, Lou Fisher <bhu1954@...> wrote:
Good luck I bought the thumbdv about two years ago. Got the new version and it worked great for about two years. Now have similar problems seems about two months ago several just quit working.  I know of at least ten different people with same problem all happening at about same time.  If anyone has any solutions please post we loved our thumbdvs

--


John D. Hays
Edmonds, WA
K7VE

   


Luke.evans@...
 

Thanks everyone for the responses.

Yes, it's macOS and Buster. 

I've checked out the issues page, and this catches my eye:

Sorry Bryan - I get it now.

The early ThumbDV has a HARDware issue - so it is just a case of put up with it or get a new revision ThumbDV, I guess? I assume this cannot be fixed in software. It's no great shakes...

Thanks for your assistance.

That doesn't bode well, as I'm pretty sure I have a very early ThumbDV.

However, I can say for sure that I have unplugged and reinserted the ThumbDV, which is the suggested workaround for the "hardware issue" that is blamed for the connection to the device being broken when a machine sleeps.  In my case, I can't get the software to connect to the device on the *first* occasion.

I did wonder whether new tighter sandboxing (security) restrictions for App Store Mac apps might have left the app unable to negotiate the rights to connect directly to hardware with the OS.  However, I think I see other people able to use the device with macOS High Sierra, which probably disproves that theory.  

I have also tried setting both available serial speeds, with no luck (I assume there's an attempt to reconnect to the device when the speed is changed - though there's no visible confirmation that the new speed is active).  In any case, I've also tried unplugging and reconnecting the hardware with each speed selected. 


 

Have you pulled the latest update from the App store?


On Wed, Jul 4, 2018, 16:41 <Luke.evans@...> wrote:
Thanks everyone for the responses.

Yes, it's macOS and Buster. 

I've checked out the issues page, and this catches my eye:

Sorry Bryan - I get it now.

The early ThumbDV has a HARDware issue - so it is just a case of put up with it or get a new revision ThumbDV, I guess? I assume this cannot be fixed in software. It's no great shakes...

Thanks for your assistance.

That doesn't bode well, as I'm pretty sure I have a very early ThumbDV.

However, I can say for sure that I have unplugged and reinserted the ThumbDV, which is the suggested workaround for the "hardware issue" that is blamed for the connection to the device being broken when a machine sleeps.  In my case, I can't get the software to connect to the device on the *first* occasion.

I did wonder whether new tighter sandboxing (security) restrictions for App Store Mac apps might have left the app unable to negotiate the rights to connect directly to hardware with the OS.  However, I think I see other people able to use the device with macOS High Sierra, which probably disproves that theory.  

I have also tried setting both available serial speeds, with no luck (I assume there's an attempt to reconnect to the device when the speed is changed - though there's no visible confirmation that the new speed is active).  In any case, I've also tried unplugging and reconnecting the hardware with each speed selected. 


AB4WS - Jack
 

I have one of the original ThumbDV and with the new update to Buster is working fiNe. I am even using it connected to Raspberry Pi running Ambe Server with buster with no issues, after the recent Buster update for high Sherri’s.

73 de AB4WS,

Jack


On Jul 4, 2018, at 19:42, Luke.evans@... wrote:

Thanks everyone for the responses.

Yes, it's macOS and Buster. 

I've checked out the issues page, and this catches my eye:

Sorry Bryan - I get it now.

The early ThumbDV has a HARDware issue - so it is just a case of put up with it or get a new revision ThumbDV, I guess? I assume this cannot be fixed in software. It's no great shakes...

Thanks for your assistance.

That doesn't bode well, as I'm pretty sure I have a very early ThumbDV.

However, I can say for sure that I have unplugged and reinserted the ThumbDV, which is the suggested workaround for the "hardware issue" that is blamed for the connection to the device being broken when a machine sleeps.  In my case, I can't get the software to connect to the device on the *first* occasion.

I did wonder whether new tighter sandboxing (security) restrictions for App Store Mac apps might have left the app unable to negotiate the rights to connect directly to hardware with the OS.  However, I think I see other people able to use the device with macOS High Sierra, which probably disproves that theory.  

I have also tried setting both available serial speeds, with no luck (I assume there's an attempt to reconnect to the device when the speed is changed - though there's no visible confirmation that the new speed is active).  In any case, I've also tried unplugging and reconnecting the hardware with each speed selected. 


Luke.evans@...
 

Hmm.  I've tried this on two Macs now (both with High Sierra), one with a built-in classic USB and one with a USB-C and dongle.

The hardware is detected (see device tree dump below for the USB-C Mac), but in the logs, Buster says:
default 21:32:17.546349 -0700 Buster -[BTRDV3KSerialVocoder openPort] [Line 303] Opening /dev/cu.usbserial-DA01PMV0 at 460800 baud
default 21:32:17.549735 -0700 Buster -[BTRDV3KVocoder start] [Line 194] Port opened, initializing
default 21:32:18.558880 -0700 Buster -[BTRDV3KVocoder start] [Line 204] Couldn't Reset DV3000: Undefined error: 0
default 21:32:23.780466 -0700 Buster -[BTRDV3KSerialVocoder openPort] [Line 303] Opening /dev/cu.usbserial-DA01PMV0 at 230400 baud
default 21:32:23.783554 -0700 Buster -[BTRDV3KVocoder start] [Line 194] Port opened, initializing
default 21:32:24.791905 -0700 Buster -[BTRDV3KVocoder start] [Line 204] Couldn't Reset DV3000: Undefined error: 0
 
So, as you can see I have tried both serial speeds.  Apparently the port is opened, but then there's an error 'starting the vocoder' in the class method "start" on "BTRDV3KVocoder".  "Undefined error" isn't very helpful, but at least we can see the line of code where the problem is reported. 

I checked in latest GitHub sources and around line 204, I see:

NSLog(@"Port opened, initializing");
    
//  Initialize the DV3K
struct dv3k_packet ctrlPacket = {
    .start_byte = DV3K_START_BYTE,
    .header.packet_type = DV3K_TYPE_CONTROL,
    .header.payload_length = htons(1),
    .payload.ctrl.field_id = DV3K_CONTROL_RESET
};
if(![self sendCtrlPacket:ctrlPacket expectResponse:DV3K_CONTROL_READY]) {
    NSLog(@"Couldn't Reset DV3000: %s\n", strerror(errno));
    [self closePort];
    return NO;
}

So, all that can be surmised is that the expected response (DV3K_CONTROL_READY) is not received in response to the DV3K_CONTROL_RESET message.  

I should point out that as well as the device (at least the serial controller) being discovered on the USB bus, I do also see brief flashes of a status light on the ThumbDV, so the product isn't entirely dead!

I guess at this point, I need to contact the author of Buster :-/


-----------------
Device tree:

USB 3.0 Bus:

 

  Host Controller Driver: AppleUSBXHCISPT

  PCI Device ID: 0xa12f 

  PCI Revision ID: 0x0031 

  PCI Vendor ID: 0x8086 

 

USB2.0 Hub             :

 

  Product ID: 0x2812

  Vendor ID: 0x2109  (VIA Labs, Inc.)

  Version: 90.90

  Speed: Up to 480 Mb/sec

  Manufacturer: VIA Labs, Inc.         

  Location ID: 0x14500000 / 2

  Current Available (mA): 500

  Current Required (mA): 0

  Extra Operating Current (mA): 0

 

FT230X Basic UART:

 

  Product ID: 0x6015

  Vendor ID: 0x0403  (Future Technology Devices International Limited)

  Version: 10.00

  Serial Number: DA01PMV0

  Speed: Up to 12 Mb/sec

  Manufacturer: FTDI

  Location ID: 0x14530000 / 4

  Current Available (mA): 500

  Current Required (mA): 90

  Extra Operating Current (mA): 0

 


Annaliese McDermond
 

Buster looks at the serial port, opens it, and tries to send an “reset” packet to the DVSI chip. It should hear a “ready” packet back if it’s successful and the DVSI chip is online. If the DVSI chip receives a “reset” packet at the wrong baud rate, it tends to go out to lunch. Unfortunately, there’s not much I can do about that. You need to remove the dongle and reinsert it.

The procedure that works the best is this:

Open the “Preferences” pane and go to the “Vocoder” panel.
Set the drop-dwon to 230400 baud rate.
Remove your ThumbDV. Do not do anything with Buster. Especially do not close it.
Insert the ThumbDV. Do not do anything with Buster. Especially do not close it.

At this point the version fields in Buster should populate as it talks to the DVSI chip. If it *doesn’t* do this, you could have a bad ThumbDV. All the blinky lights mean is that the FTDI chip is transmitting packets to the DVSI chip; not that the DVSI chip works in any way.

--
Annaliese McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

On Jul 4, 2018, at 9:54 PM, Luke.evans@... wrote:

Hmm. I've tried this on two Macs now (both with High Sierra), one with a built-in classic USB and one with a USB-C and dongle.

The hardware is detected (see device tree dump below for the USB-C Mac), but in the logs, Buster says:
default 21:32:17.546349 -0700 Buster -[BTRDV3KSerialVocoder openPort] [Line 303] Opening /dev/cu.usbserial-DA01PMV0 at 460800 baud
default 21:32:17.549735 -0700 Buster -[BTRDV3KVocoder start] [Line 194] Port opened, initializing
default 21:32:18.558880 -0700 Buster -[BTRDV3KVocoder start] [Line 204] Couldn't Reset DV3000: Undefined error: 0
default 21:32:23.780466 -0700 Buster -[BTRDV3KSerialVocoder openPort] [Line 303] Opening /dev/cu.usbserial-DA01PMV0 at 230400 baud
default 21:32:23.783554 -0700 Buster -[BTRDV3KVocoder start] [Line 194] Port opened, initializing
default 21:32:24.791905 -0700 Buster -[BTRDV3KVocoder start] [Line 204] Couldn't Reset DV3000: Undefined error: 0

So, as you can see I have tried both serial speeds. Apparently the port is opened, but then there's an error 'starting the vocoder' in the class method "start" on "BTRDV3KVocoder". "Undefined error" isn't very helpful, but at least we can see the line of code where the problem is reported.

I checked in latest GitHub sources and around line 204, I see:

NSLog(@"Port opened, initializing");

// Initialize the DV3K
struct dv3k_packet ctrlPacket = {
.start_byte = DV3K_START_BYTE,
.header.packet_type = DV3K_TYPE_CONTROL,
.header.payload_length = htons(1),
.payload.ctrl.field_id = DV3K_CONTROL_RESET
};
if(![self sendCtrlPacket:ctrlPacket expectResponse:DV3K_CONTROL_READY]) {
NSLog(@"Couldn't Reset DV3000: %s\n", strerror(errno));
[self closePort];
return NO;
}

So, all that can be surmised is that the expected response (DV3K_CONTROL_READY) is not received in response to the DV3K_CONTROL_RESET message.

I should point out that as well as the device (at least the serial controller) being discovered on the USB bus, I do also see brief flashes of a status light on the ThumbDV, so the product isn't entirely dead!

I guess at this point, I need to contact the author of Buster :-/


-----------------
Device tree:
USB 3.0 Bus:

Host Controller Driver: AppleUSBXHCISPT
PCI Device ID: 0xa12f
PCI Revision ID: 0x0031
PCI Vendor ID: 0x8086

USB2.0 Hub :

Product ID: 0x2812
Vendor ID: 0x2109 (VIA Labs, Inc.)
Version: 90.90
Speed: Up to 480 Mb/sec
Manufacturer: VIA Labs, Inc.
Location ID: 0x14500000 / 2
Current Available (mA): 500
Current Required (mA): 0
Extra Operating Current (mA): 0

FT230X Basic UART:

Product ID: 0x6015
Vendor ID: 0x0403 (Future Technology Devices International Limited)
Version: 10.00
Serial Number: DA01PMV0
Speed: Up to 12 Mb/sec
Manufacturer: FTDI
Location ID: 0x14530000 / 4
Current Available (mA): 500
Current Required (mA): 90
Extra Operating Current (mA): 0


 

If it doesn't work at 230400, wouldn't you repeat the process at 460800?

On Thu, Jul 5, 2018 at 8:09 PM, Annaliese McDermond <nh6z@...> wrote:
Buster looks at the serial port, opens it, and tries to send an “reset” packet to the DVSI chip.  It should hear a “ready” packet back if it’s successful and the DVSI chip is online.  If the DVSI chip receives a “reset” packet at the wrong baud rate, it tends to go out to lunch.  Unfortunately, there’s not much I can do about that.  You need to remove the dongle and reinsert it.

The procedure that works the best is this:

Open the “Preferences” pane and go to the “Vocoder” panel.
Set the drop-dwon to 230400 baud rate.
Remove your ThumbDV.  Do not do anything with Buster.  Especially do not close it.
Insert the ThumbDV.  Do not do anything with Buster.  Especially do not close it.

At this point the version fields in Buster should populate as it talks to the DVSI chip.  If it *doesn’t* do this, you could have a bad ThumbDV.  All the blinky lights mean is that the FTDI chip is transmitting packets to the DVSI chip; not that the DVSI chip works in any way.

--
Annaliese McDermond (NH6Z)
Xenotropic Systems
mcdermj@...


> On Jul 4, 2018, at 9:54 PM, Luke.evans@... wrote:
>
> Hmm.  I've tried this on two Macs now (both with High Sierra), one with a built-in classic USB and one with a USB-C and dongle.
>
> The hardware is detected (see device tree dump below for the USB-C Mac), but in the logs, Buster says:
> default 21:32:17.546349 -0700 Buster -[BTRDV3KSerialVocoder openPort] [Line 303] Opening /dev/cu.usbserial-DA01PMV0 at 460800 baud
> default 21:32:17.549735 -0700 Buster -[BTRDV3KVocoder start] [Line 194] Port opened, initializing
> default 21:32:18.558880 -0700 Buster -[BTRDV3KVocoder start] [Line 204] Couldn't Reset DV3000: Undefined error: 0
> default 21:32:23.780466 -0700 Buster -[BTRDV3KSerialVocoder openPort] [Line 303] Opening /dev/cu.usbserial-DA01PMV0 at 230400 baud
> default 21:32:23.783554 -0700 Buster -[BTRDV3KVocoder start] [Line 194] Port opened, initializing
> default 21:32:24.791905 -0700 Buster -[BTRDV3KVocoder start] [Line 204] Couldn't Reset DV3000: Undefined error: 0
>
> So, as you can see I have tried both serial speeds.  Apparently the port is opened, but then there's an error 'starting the vocoder' in the class method "start" on "BTRDV3KVocoder".  "Undefined error" isn't very helpful, but at least we can see the line of code where the problem is reported.
>
> I checked in latest GitHub sources and around line 204, I see:
>
> NSLog(@"Port opened, initializing");
>     
> //  Initialize the DV3K
> struct dv3k_packet ctrlPacket = {
>     .start_byte = DV3K_START_BYTE,
>     .header.packet_type = DV3K_TYPE_CONTROL,
>     .header.payload_length = htons(1),
>     .payload.ctrl.field_id = DV3K_CONTROL_RESET
> };
> if(![self sendCtrlPacket:ctrlPacket expectResponse:DV3K_CONTROL_READY]) {
>     NSLog(@"Couldn't Reset DV3000: %s\n", strerror(errno));
>     [self closePort];
>     return NO;
> }
>
> So, all that can be surmised is that the expected response (DV3K_CONTROL_READY) is not received in response to the DV3K_CONTROL_RESET message.
>
> I should point out that as well as the device (at least the serial controller) being discovered on the USB bus, I do also see brief flashes of a status light on the ThumbDV, so the product isn't entirely dead!
>
> I guess at this point, I need to contact the author of Buster :-/
>
>
> -----------------
> Device tree:
> USB 3.0 Bus:
>
>   Host Controller Driver: AppleUSBXHCISPT
>   PCI Device ID: 0xa12f
>   PCI Revision ID: 0x0031
>   PCI Vendor ID: 0x8086
>
> USB2.0 Hub             :
>
>   Product ID: 0x2812
>   Vendor ID: 0x2109  (VIA Labs, Inc.)
>   Version: 90.90
>   Speed: Up to 480 Mb/sec
>   Manufacturer: VIA Labs, Inc.         
>   Location ID: 0x14500000 / 2
>   Current Available (mA): 500
>   Current Required (mA): 0
>   Extra Operating Current (mA): 0
>
> FT230X Basic UART:
>
>   Product ID: 0x6015
>   Vendor ID: 0x0403  (Future Technology Devices International Limited)
>   Version: 10.00
>   Serial Number: DA01PMV0
>   Speed: Up to 12 Mb/sec
>   Manufacturer: FTDI
>   Location ID: 0x14530000 / 4
>   Current Available (mA): 500
>   Current Required (mA): 90
>   Extra Operating Current (mA): 0
>
>










--


John D. Hays
Edmonds, WA
K7VE

   


Luke.evans@...
 

On Thu, Jul 5, 2018 at 08:40 pm, John D Hays - K7VE wrote:
If it doesn't work at 230400, wouldn't you repeat the process at 460800?
Indeed you would :)

Finally, the procedure outlined by Annaliese, including the trying it again with 460800, worked for me. 
Hoorah! 

I think I was previous having it fail, then closing Buster, believing that it would be better to try again with it 'clean' startup.  I had certainly been unplugging and reinserting the dongle *a lot* and indeed changing between the two serial speeds, but obviously this trick was to leave Buster running and trust that reinserting the USB would cause all the right handshaking to restart. 

Anyway, thanks to all.  I finally get to enjoy Buster :) 


Gary McBroom <73064macgyver@...>
 

I have just installed Buster on a MacBook Pro.  Everything is working on the receive side but I am unable to transmit.  Anyone have any suggestions?


On Thu, Jul 5, 2018, 11:41 PM <Luke.evans@...> wrote:
On Thu, Jul 5, 2018 at 08:40 pm, John D Hays - K7VE wrote:
If it doesn't work at 230400, wouldn't you repeat the process at 460800?
Indeed you would :)

Finally, the procedure outlined by Annaliese, including the trying it again with 460800, worked for me. 
Hoorah! 

I think I was previous having it fail, then closing Buster, believing that it would be better to try again with it 'clean' startup.  I had certainly been unplugging and reinserting the dongle *a lot* and indeed changing between the two serial speeds, but obviously this trick was to leave Buster running and trust that reinserting the USB would cause all the right handshaking to restart. 

Anyway, thanks to all.  I finally get to enjoy Buster :) 


Annaliese McDermond
 



On Jul 5, 2018, at 9:41 PM, Luke.evans@... wrote:

On Thu, Jul 5, 2018 at 08:40 pm, John D Hays - K7VE wrote:
If it doesn't work at 230400, wouldn't you repeat the process at 460800?
Indeed you would :)

Finally, the procedure outlined by Annaliese, including the trying it again with 460800, worked for me. 
Hoorah! 

I think I was previous having it fail, then closing Buster, believing that it would be better to try again with it 'clean' startup.  I had certainly been unplugging and reinserting the dongle *a lot* and indeed changing between the two serial speeds, but obviously this trick was to leave Buster running and trust that reinserting the USB would cause all the right handshaking to restart. 

Buster tries to remember the last working setup and always use that if it can.  That’s why restarting it doesn’t always help, because when you initially use the program, there is no good setup, so it can sometimes get confused.  I’ve tried to do an automatic baud rate detection, but without a hardware reset on the AMBE chip, it’s pretty much impossible.

— Anna



Anyway, thanks to all.  I finally get to enjoy Buster :) 


Annaliese McDermond
 

Are you sure you have v1.2.1, the latest on the app store?  There was a bug with entitlements that cause it to fail to be able to get the microphone device.

— Anna

On Jul 5, 2018, at 10:18 PM, Gary McBroom <73064macgyver@...> wrote:

I have just installed Buster on a MacBook Pro.  Everything is working on the receive side but I am unable to transmit.  Anyone have any suggestions?

On Thu, Jul 5, 2018, 11:41 PM <Luke.evans@...> wrote:
On Thu, Jul 5, 2018 at 08:40 pm, John D Hays - K7VE wrote:
If it doesn't work at 230400, wouldn't you repeat the process at 460800?
Indeed you would :)

Finally, the procedure outlined by Annaliese, including the trying it again with 460800, worked for me. 
Hoorah! 

I think I was previous having it fail, then closing Buster, believing that it would be better to try again with it 'clean' startup.  I had certainly been unplugging and reinserting the dongle *a lot* and indeed changing between the two serial speeds, but obviously this trick was to leave Buster running and trust that reinserting the USB would cause all the right handshaking to restart. 

Anyway, thanks to all.  I finally get to enjoy Buster :)