BradC, for USB, is the third pin needed to handle the initial pull-up/down on one of the two data pins? If we have pull-up/down on every pin, will it still need three pins then? I see what you are saying about the enumeration headache. The purpose of USB would be, at least, to provide a development conduit to the PC. Also, users could do other things, as well. SD card in 4 pins would be nice.
Yeah, the third pin is for the enable resistor. The issue is it has to be quite a specific value (between about 1.2-1.5k). It also has to be at the port, whereas you need ~100 Ohm series resistors between D+/- and the port. Deviating from this can cause some pretty big headaches. Also, you can't just hardwire it as you *need* to be able to respond to an enumeration request quite quickly after the enable is pulled or the host will call the device dead and shut down the port.
From what you've said about speed, the P-II will do full-speed USB standing on its head, and might even be able to do the MAC layer and application level in the same cog (I had to split them to be able to get responses out in time). There will be no problems at all for users to be able to do their own thing with that. As a conduit for development, just emulating a serial port would do a great job as you have no speed restrictions at all. 1MB/s is quite doable over a full-speed USB link.
Something like this might work.
<try all other boot methods first>
pull enable high
wait 1 second for enumeration (halt on fail)
enumerate
wait 5 seconds for further instruction (or don't timeout at all and just sit there waiting for the host software)
go to sleep
On the PC end you would register a notification that a new USB device had arrived. If it matched the PID/VID of the prop you have a couple of seconds to try and talk to it.
Reset could be an issue.
When I played with the USB bootloader, I had 2 cogs that ran full time in the background (communicated using the last 8 longs of RAM) so I could "remote reset" the chip. That way I never lost communication with the propeller. I could also stop all the application cogs, re-load ram, read/write eeprom, hard reset or warm-boot the chip (as long as the application did not change the oscillator settings!). It was a neat way to do it, but at an absolute maximum of 1000 8 bytes packets per second (reality was more like 600) it was _very_ slow to do anything.
Plenty of time to work out the finer details anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
BradC:
USB: As a slave, there is only 2 pins D+ & D- plus power & gnd. I presume when we use the FTDI chip, because the USB bus is already established with the pc, the enumeration (connection) time is not an issue? So I guess, that if PropII were to use USB to download it would have to enumerate a USB connection and then wait and see if something sends a download sequence to it and this would be a long process timewise. Also, the download would have to work differently or we would be resetting the enumeration sequence (and we know windoze doesnt like that). Sounds complicated.
Chip:
microSD: uses 4 pins with SPI protocol. Native SD mode is licensed, so forget that. The 4 pins are -CS, SCLK, DI, DO. I am unsure if DI and DO could be joined or if there is a possibility of overlap causing contention. I do not know enough about the protocol to know if it could share a standard SPI interface. Certainly, the uSD could as long as -CS is high, and that DO (from uSD) is forced into tri-state - I do this on the TriBlade which is shares SCLK, DI & DO with the SRAM. But I am not sure if any another SPI chip on the uSD SPI bus could mis-interpret data to/from the uSD.
Boot code: Presuming the load options are on different pins, it would be possible to launch multiple cogs and each of them concurrently try to establish communications with the various bootable devices (Hey, may as well utilise the cogs in the boot process). If the user can program a few fuse bits, the boot code could detect that to disable various boot options. Are the fuses OTP?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Chip Gracey (Parallax) said...
We're currently looking at making a special 12x12mm 128-pin LQFP that has a big GND plate on the bottom. This way, no pins need to be spent on GND and we can get over three 32-pin ports out.
Single big GND plates are a pain to hand solder unless you put some pretty big vias in and solder from below or carefully use a hot air gun. Please reconsider and put GND's on pins.
Single big GND plates are a pain to hand solder unless you put some pretty big vias in and solder from below or carefully use a hot air gun. Please reconsider and put GND's on pins.
I hear you, but that ground plate would save a GND pin for every 8 I/Os, plus 8 more for the core. This comes to about 20 pins. Those can now be I/Os, instead. Just put four .1" plated-through holes under the chip so that you could surely solder it from the backside.
You can solder chips with a ground plate using a hotplate quite successfully even on single sided boards. The main issue seems to be maintaining alignment, a jig would make things easier. I'm really pleased to here about the possible LQFP-128 option, I was starting to imagine something I could only use with a breakout board.
As Brad described, the 3. Pin is needed to switch the PullUp on D- (LowSpeed) or D+ (FullSpeed) on and off. But this can also be made internal in the PropII with 2 switchable 1.5k PullUps.
Another Problem that I see with USB Boot is the Clock frequency. I don't think the internal Oscillator is precise enough, and the Application which defines the Frequency of the connected crystal is not startet then, so the USB boot code will work only with one certain crystal frequency (?)
Another Problem that I see with USB Boot is the Clock frequency. I don't think the internal Oscillator is precise enough, and the Application which defines the Frequency of the connected crystal is not startet then, so the USB boot code will work only with one certain crystal frequency (?)
Great catch Andy! I hadn't thought of that. Especially with full speed USB, the clock must be very accurate. low speed allows 1.5% deviation to cater for very cheap slaves, but full speed is _much_ tighter.
<edit>
Given how fast the new chip is going to be, it's entirely possible that provided a crystal oscillator is used, the code might be able to "autobaud" to adjust for any potential crystal frequency provided it's fast enough. It would be an interesting challenge.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Ariba said...
As Brad described, the 3. Pin is needed to switch the PullUp on D- (LowSpeed) or D+ (FullSpeed) on and off. But this can also be made internal in the PropII with 2 switchable 1.5k PullUps.
Another Problem that I see with USB Boot is the Clock frequency. I don't think the internal Oscillator is precise enough, and the Application which defines the Frequency of the connected crystal is not startet then, so the USB boot code will work only with one certain crystal frequency (?)
Andy
About these pullups: would we need 1.5k switchable to both VSS and VDD, or just one of them? I'm working on the pin circuitry, still, so I can find a way to add this.
Because the next Prop has the ability to multiply the crystal input by 1x through 16x, I'm thinking that maybe it wouldn't be a bad thing to standardize on a 20MHz crystal. At 20MHz+, you can get minimally-sized crystals. 10Mhz crystals are still big. The oscillator circuit was designed to target 20Mhz crystals. With a known frequency base, USB timing issues go away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/24/2009 11:50:12 AM GMT
Chip Gracey (Parallax) said...
About these pullups: would we need 1.5k switchable to both VSS and VDD, or just one of them? I'm working on the pin circuitry, still, so I can find a way to add this.
The pullup only needs to be switchable to VDD.
The issue I guess is the series resistors. The USB spec is pretty tight (USB2.0 Spec - Section 7.1) on having the driver impedance limited by 45Ohm (I used 68 as it's what I had available at the time) series resistors. The signalling pull up is at the port, not at the driver, so unless you build 45 Ohm series resistors into the silicon and the 1.2K pullups (one for each pin so you could use full & low speed) then using 3 pins and 3 external resistors is certainly easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Chip said...
We're currently looking at making a special 12x12mm 128-pin LQFP that has a big GND plate on the bottom. This way, no pins need to be spent on GND and we can get over three 32-pin ports out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Toby Seckshund said...
Would 20MHz be a good starting frequency? Every time I have seen the xtals for USB, of any speed, they seem to be multiples of 6 or 12MHz.
How about 20Mhz stepped up 6x to 120MHz? That would certainly jive.
The issue I guess is the series resistors. The USB spec is pretty tight (USB2.0 Spec - Section 7.1) on having the driver impedance limited by 45Ohm (I used 68 as it's what I had available at the time) series resistors. The signalling pull up is at the port, not at the driver, so unless you build 45 Ohm series resistors into the silicon and the 1.2K pullups (one for each pin so you could use full & low speed) then using 3 pins and 3 external resistors is certainly easier.
We could build +/-15% tolerance resistors into the pin drivers. So, is it 1.2K or 1.5K that we'd want? And just to VDD, with VDD being 3.3v? I could easily give every pin a pull-up resistor of the nominal value needed. How fast would this pull up need to be turned on or off? I ask because it might mean toggling the pin through some modes that will take a few clocks.
How about 20Mhz stepped up 6x to 120MHz? That would certainly jive.
Is it a single clock per instruction cycle? That would buy us 10 instructions per bit. The current USB receive code uses 11 instructions per bit for 1.5Mhz NRZI encoding with bit unstuffing. It might be a bit tight at 120MIPS for a 12MHZ bit rate, but then I'm sure someone could make the receive code more efficient than I have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
How about 20Mhz stepped up 6x to 120MHz? That would certainly jive.
Is it a single clock per instruction cycle? That would buy us 10 instructions per bit. The current USB receive code uses 11 instructions per bit for 1.5Mhz NRZI encoding with bit unstuffing. It might be a bit tight at 120MIPS for a 12MHZ bit rate, but then I'm sure someone could make the receive code more efficient than I have.
It's single-clock instructions.
How about those pull-ups? We could put those in the pin driver and then have just two series resistors on the outside (no third pin and 1.5k resistor, then).
Chip Gracey (Parallax) said...
We could build +/-15% tolerance resistors into the pin drivers. So, is it 1.2K or 1.5K that we'd want? And just to VDD, with VDD being 3.3v? I could easily give every pin a pull-up resistor of the nominal value needed. How fast would this pull up need to be turned on or off? I ask because it might mean toggling the pin through some modes that will take a few clocks.
The spec says 1.5k to 3.3v. I think I used 1.2k as it was all I had handy. The USB signals are all 3.3v, so a perfect match for the current I/O pins.
In this context, speed for the pullups is completely unimportant. The pullup is like the on/off switch for the interface. Turn it on, sit and wait for the host to throw us a packet. When we're done with the interface we drop the pullup to tell the host we are no longer plugged in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Chip Gracey (Parallax) said...
We could build +/-15% tolerance resistors into the pin drivers. So, is it 1.2K or 1.5K that we'd want? And just to VDD, with VDD being 3.3v? I could easily give every pin a pull-up resistor of the nominal value needed. How fast would this pull up need to be turned on or off? I ask because it might mean toggling the pin through some modes that will take a few clocks.
This PullUp needs only be 1 time switched on when the USB driver is ready, and switched off when the USB driver stops, so no need for speed.
Attached is a good understanding USB description, on page 6 is a schematic of the host - device connection. They say 1.5k +-5%, but I think 15% is also OK, perhaps make it 1.4k Ohm then.
How about those pull-ups? We could put those in the pin driver and then have just two series resistors on the outside (no third pin and 1.5k resistor, then).
That's what I was getting at with the little schematic I posted. The USB spec is pretty specific on the pullup being on the port end of the series resistor, not at the driver end. I guess when you are whacking 12MHZ down a line the termination is pretty important.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Central pads like those on the proposed package are normally reflow soldered with solder paste. The stencil needs to be made with a grid pattern so that the chip doesn't float on the molten solder. For hand-soldered prototypes the technique Chip mentioned works very well - I often use it with QFN packages using a single 2 mm via. For a large device like the Propeller II you will need good soldering equipment, like Metcal, to get adequate heat transfer.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Comments
Yeah, the third pin is for the enable resistor. The issue is it has to be quite a specific value (between about 1.2-1.5k). It also has to be at the port, whereas you need ~100 Ohm series resistors between D+/- and the port. Deviating from this can cause some pretty big headaches. Also, you can't just hardwire it as you *need* to be able to respond to an enumeration request quite quickly after the enable is pulled or the host will call the device dead and shut down the port.
From what you've said about speed, the P-II will do full-speed USB standing on its head, and might even be able to do the MAC layer and application level in the same cog (I had to split them to be able to get responses out in time). There will be no problems at all for users to be able to do their own thing with that. As a conduit for development, just emulating a serial port would do a great job as you have no speed restrictions at all. 1MB/s is quite doable over a full-speed USB link.
Something like this might work.
<try all other boot methods first>
pull enable high
wait 1 second for enumeration (halt on fail)
enumerate
wait 5 seconds for further instruction (or don't timeout at all and just sit there waiting for the host software)
go to sleep
On the PC end you would register a notification that a new USB device had arrived. If it matched the PID/VID of the prop you have a couple of seconds to try and talk to it.
Reset could be an issue.
When I played with the USB bootloader, I had 2 cogs that ran full time in the background (communicated using the last 8 longs of RAM) so I could "remote reset" the chip. That way I never lost communication with the propeller. I could also stop all the application cogs, re-load ram, read/write eeprom, hard reset or warm-boot the chip (as long as the application did not change the oscillator settings!). It was a neat way to do it, but at an absolute maximum of 1000 8 bytes packets per second (reality was more like 600) it was _very_ slow to do anything.
Plenty of time to work out the finer details anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
USB: As a slave, there is only 2 pins D+ & D- plus power & gnd. I presume when we use the FTDI chip, because the USB bus is already established with the pc, the enumeration (connection) time is not an issue? So I guess, that if PropII were to use USB to download it would have to enumerate a USB connection and then wait and see if something sends a download sequence to it and this would be a long process timewise. Also, the download would have to work differently or we would be resetting the enumeration sequence (and we know windoze doesnt like that). Sounds complicated.
Chip:
microSD: uses 4 pins with SPI protocol. Native SD mode is licensed, so forget that. The 4 pins are -CS, SCLK, DI, DO. I am unsure if DI and DO could be joined or if there is a possibility of overlap causing contention. I do not know enough about the protocol to know if it could share a standard SPI interface. Certainly, the uSD could as long as -CS is high, and that DO (from uSD) is forced into tri-state - I do this on the TriBlade which is shares SCLK, DI & DO with the SRAM. But I am not sure if any another SPI chip on the uSD SPI bus could mis-interpret data to/from the uSD.
Boot code: Presuming the load options are on different pins, it would be possible to launch multiple cogs and each of them concurrently try to establish communications with the various bootable devices (Hey, may as well utilise the cogs in the boot process). If the user can program a few fuse bits, the boot code could detect that to disable various boot options. Are the fuses OTP?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The fuse bits are OTP. They are actually poly fuses that get blown.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
USB3?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Single big GND plates are a pain to hand solder unless you put some pretty big vias in and solder from below or carefully use a hot air gun. Please reconsider and put GND's on pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
And you need three pins on the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Graham
Neither.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Another Problem that I see with USB Boot is the Clock frequency. I don't think the internal Oscillator is precise enough, and the Application which defines the Frequency of the connected crystal is not startet then, so the USB boot code will work only with one certain crystal frequency (?)
Andy
Great catch Andy! I hadn't thought of that. Especially with full speed USB, the clock must be very accurate. low speed allows 1.5% deviation to cater for very cheap slaves, but full speed is _much_ tighter.
<edit>
Given how fast the new chip is going to be, it's entirely possible that provided a crystal oscillator is used, the code might be able to "autobaud" to adjust for any potential crystal frequency provided it's fast enough. It would be an interesting challenge.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Because the next Prop has the ability to multiply the crystal input by 1x through 16x, I'm thinking that maybe it wouldn't be a bad thing to standardize on a 20MHz crystal. At 20MHz+, you can get minimally-sized crystals. 10Mhz crystals are still big. The oscillator circuit was designed to target 20Mhz crystals. With a known frequency base, USB timing issues go away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/24/2009 11:50:12 AM GMT
The pullup only needs to be switchable to VDD.
The issue I guess is the series resistors. The USB spec is pretty tight (USB2.0 Spec - Section 7.1) on having the driver impedance limited by 45Ohm (I used 68 as it's what I had available at the time) series resistors. The signalling pull up is at the port, not at the driver, so unless you build 45 Ohm series resistors into the silicon and the 1.2K pullups (one for each pin so you could use full & low speed) then using 3 pins and 3 external resistors is certainly easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Chris
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
How about 20Mhz stepped up 6x to 120MHz? That would certainly jive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Is it a single clock per instruction cycle? That would buy us 10 instructions per bit. The current USB receive code uses 11 instructions per bit for 1.5Mhz NRZI encoding with bit unstuffing. It might be a bit tight at 120MIPS for a 12MHZ bit rate, but then I'm sure someone could make the receive code more efficient than I have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
How about those pull-ups? We could put those in the pin driver and then have just two series resistors on the outside (no third pin and 1.5k resistor, then).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
The spec says 1.5k to 3.3v. I think I used 1.2k as it was all I had handy. The USB signals are all 3.3v, so a perfect match for the current I/O pins.
In this context, speed for the pullups is completely unimportant. The pullup is like the on/off switch for the interface. Turn it on, sit and wait for the host to throw us a packet. When we're done with the interface we drop the pullup to tell the host we are no longer plugged in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
This PullUp needs only be 1 time switched on when the USB driver is ready, and switched off when the USB driver stops, so no need for speed.
Attached is a good understanding USB description, on page 6 is a schematic of the host - device connection. They say 1.5k +-5%, but I think 15% is also OK, perhaps make it 1.4k Ohm then.
Andy
That's what I was getting at with the little schematic I posted. The USB spec is pretty specific on the pullup being on the port end of the series resistor, not at the driver end. I guess when you are whacking 12MHZ down a line the termination is pretty important.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/24/2009 12:53:49 PM GMT