jks

Sorry, I'm neck deep in a new project and just skimming these long posts. Perhaps Seeed put the wrong reel of resistors on the pick-and-place machine resulting in a bunch of BBGs built with a 3.5k going into R136 instead of the 0.1 ohm called out on the schematic (same as on the BBB). This is the only 0.1R 0805 resistor on the schematic as far as I can tell.

It's also worth noting that the SEEED metal case does not have a direct connection between the antenna ground, or any ground, that may or may not, be provided by the DC input cable. So the metal case is effectively 'floating' at whatever potential it likes, relative to the other ground connections.

I first read this as implying there was no connection between the antenna ground (SMA outer threads or green header block GND terminal) and the Kiwi, Beagle or enclosure grounds. Just to be clear, that notion is false. They are all grounded together. It is true that the ground of the DC input passes through the CMC which has a significant resistance from a grounding/ESD perspective.

What the Kiwi doesn't have is a ground loop that would occur if the outer RF SMA threads were attached to the metal enclosure. That's why there is that oversized cutout surrounding the SMAs. I actually measured a small increase in the noise floor during enclosure design with the RF SMA connected to the enclosure.

The question of establishing a proper system/ESD ground is very valid. Most of this has to be solved external to the Kiwi. Probably a stiff earth ground wire should be attached to one of the screws of the enclosure and a power supply and antenna connection used that does not provide a DC path to earth ground. It important to note the Ethernet RJ45 is transformer coupled for ground loop / safety considerations. But voltage spikes/pulses can still get through hence the ESD precautions.

The BBG schematic and RJ45 schematic are attached. The scrubbed values on the RJ45 are 75 ohms and 1000 pF.

FWIW, Mouser USA is currently showing 4 enclosures in stock. I don't recall seeing this before. Shipping will be faster and less expensive than buying from Seeed for those of you in the USA: http://www.mouser.com/Search/Refine.aspx?Keyword=kiwisdr

There was a change made in v1.240 that fixes one problem for the guys making >= 6 kiwiclient connections for use with the external WSPR processing script. But it involved making a "risky" change to the task priority of the internal web server of the Kiwi. I was very worried this might cause problems with the real-time response of the audio tasks. And, despite all my testing, this now seems to be the case.

So I'll revert that change in today's update and hopefully that will fix it. We'll have to find some other solution for the WSPR guys.

When you mentioned "external decoders" I assumed you were interested in I/Q obtained from the L/R channels of the browser audio output, e.g. so the browser could be used to control the Kiwi. It is indeed possible to connect over the network (via web sockets) to the Kiwi server and issue the same API commands as the browser UI does to set frequency etc.

An example written in Python that works on Linux/OS X is called kiwiclient/kiwirecorder available here: https://github.com/jks-prv/kiwiclient/tree/jks-v0.1 It is capable of recording to .wav files but there is no reason you couldn't stream to another application. I think Christoph was working on (or has working) an interface to GNUradio this way. The I/Q mode bandwidth is of course limited to the audio channel bandwidth (currently 12 kHz).

No time soon. I have to do something about mobile. It's intolerable. And Daniel has been rightfully taking me to task, viz:

Press 'x' to quickly toggle the visibility of all control panels.

Press 'y' to toggle the top bar and band/tag bars as follows: both visible, one visible, the other visible, none visible. The frequency scale remains always visible.

Mobile-device equivalents of this, and mobile improvements in general, are being thought about.

When you mentioned "external decoders" I assumed you were interested in I/Q obtained from the L/R channels of the browser audio output, e.g. so the browser could be used to control the Kiwi. It is indeed possible to connect over the network (via web sockets) to the Kiwi server and issue the same API commands as the browser UI does to set frequency etc.

An example written in Python that works on Linux/OS X is called kiwiclient/kiwirecorder available here: https://github.com/jks-prv/kiwiclient/tree/jks-v0.1 It is capable of recording to .wav files but there is no reason you couldn't stream to another application. I think Christoph was working on (or has working) an interface to GNUradio this way. The I/Q mode bandwidth is of course limited to the audio channel bandwidth (currently 12 kHz).

Press 'x' to quickly toggle the visibility of all control panels.

Press 'y' to toggle the top bar and band/tag bars as follows: both visible, one visible, the other visible, none visible. The frequency scale remains always visible.

Mobile-device equivalents of this, and mobile improvements in general, are being thought about.

Press 'x' to quickly toggle the visibility of all control panels.

Press 'y' to toggle the top bar and band/tag bars as follows: both visible, one visible, the other visible, none visible. The frequency scale remains always visible.

Mobile-device equivalents of this, and mobile improvements in general, are being thought about.