M0KHZ’s Blog

This is a quick blog update, sharing an interesting application – CQ100.

This is a Ham only voice over IP system, it looks very interesting, I’ve downloaded a copy of the program and have uploaded my license for authentication, I’ll let you know how I get on once I’m on the system

Here is a quick breakdown of the specs:

• Just works right “out of the box” with no need to configure router ports.
  This means it can be used from hotel rooms, airports, public libraries, internet cafes, etc.
• Covers 5 HF radio bands - 80, 40, 20, 15 and 10 meter bands.
• Computer microphone provides voice modulation.
• Includes built in CW keyer. Simply type on the keyboard to send perfect CW.
• Spectrum graph shows radio activity within a settable sweep range of 50, 100, 200 and 500 kHz.
• Call sign, handle, QTH, etc are automatically displayed for current transmitting station.
• Keyboard “Hot Keys” provide a simple interface for vision impaired operators.
• “Round-Table” QSO’s are possible because any frequency may have a large number of listeners.

System Requirements:

CQ100 requires Windows 2000, XP or VISTA with sound card, microphone and speakers (or headset).
A reliable internet connection is required with a speed of at least 33.6k dialup.

End of update.

This is a very quick blog update, sharing the Phoenix alpha II PCB. If you remember the first board had the wrong footprint for the AD9912 DDS chip, Richard - VK6BRO has once again done a fantastic job rectifying this issue, he has also included an on-board clock source. I need to order some more parts but soldering parts will start this week

End of update

This is a quick blog update, sharing the test code and function testing of the PIC18F6722 generic development environment

The code is straight forward and incorporates the finite state machine logic, as previously mentioned this FSM will provide the framework for future projects.

Here is the two code files,

pic18f6722_dev_board

functions

Below is a video demonstrating the board and test code in action, I apologise for the quality of the recording, my web cam doesn’t have a macro facility and I had to find a compromise between focus and viewing area, but you’ll get the general idea, as you’ll see everything is working

End of update.

This is a very quick blog update, posting the QS1R near clone schematics directly to the blog.

Following a number of e mails, it seems a few readers are still using Internet Explorer as their preferred browser, and with this browser some are having problems viewing ‘Scribed’ pdf’s, so here is the schematic direct from the blog 

c_quick_schematics

Do yourself a favor and download a copy of Mozila Firefox and use this as your browser, it’s free and MUCH better than the IE xxxx  They will co-exist but I’m guessing after a very short time you’ll never use IE again.

End of update

In this blog update I will attempt to share some recent learning with respect to USB enumeration, this has recently caused some headaches regarding the ICD-U40 PIC debugger / programmer currently on loan from Paul - M1PAF, further more I need to understand this issue to understand how the Cypress USB chip on the QS1R - C_Quick integrates with the server running on the host.

A USB device defines it’s ‘personality’ by the data it supplies the host during enumeration. I will not delve very deep into this subject, for further detailed understanding there are full details of the enumeration data within the Universal Serial Bus Specification, ‘just Google for it ‘. However I will attempt to describe what happens from a high level ‘user’ perspective, without digging into, endpoints, port status etc. So with that in mind, whenever a USB device is attached to the bus, it will be enumerated by the host USB subsystem, OK so what does this mean?

You attach a device to a USB port. Or the system powers up with a device already attached. The port may be on the root hub at the host or a hub that connects downstream from the host. The hub provides power to the port, and the device is in the Powered state.

The hub detects the device. A whole series of transactions take place between the host and the device, shortly a communication channel is opened between the two and device interrogation is started, this is the first stage of enumeration. Below is a screen shot from a utility called USBTrace, as you can see a lot happens while establishing a communication channel:)

During the next phase of enumeration the host continues to interrogate the device and learns some device specific attributes, namely the Vendor ID, Product ID, and (optional) release number.

As a point of interest, you can download a utility called USBView from the FDTI website, http://www.ftdichip.com/Resources/Utilities.htm

USBView is a free utility from Microsoft that displays the USB connection tree and shows the USB devices that are connected to it together with their configuration data. This is very useful for debugging USB enumeration errors. USBView runs under Windows 98, ME, 2000 and XP.

Using this VID and PID information, the host assigns and loads a device driver. After learning about a device from its descriptors, the host looks for the best match in a device driver to manage communications with the device. In selecting a driver, Windows tries to match the information in the PC’s INF files with the Vendor ID, Product ID, and (optional) release number retrieved from the device. If there is no match, Windows looks for a match with any class, subclass, and protocol values retrieved from the device. If the device has been enumerated previously, Windows can use information in the system registry instead of searching the INF files.

OK we can now ‘see’ from a very high level what is happening here, the key information is the VID, PID and optionally Serial number retained in the device, this is where things start to get interesting.

As I mentioned earlier, I have recently had problems with the ICD-U40 USB device, somehow I managed to scramble the VID & PID information within the ICD-U40! I eventually spotted this by using USBView. Fortunately using another utility from the FTDI website, FTD2XXST, this is an EEPROM serialiser and testing utility for FT232 and FT245 devices.  FTD2XXST is based on our D2XX drivers and will work on Windows 98, ME, 2000 and XP platforms.  The latest release supports the extra features of the FT232BM and FT245BM devices as well as the AM series devices.

So after some further ‘Googling’ I discovered the correct VID & PID information for the ICD_U40, used FTD2XXST and restored the values, enabling enumeration to load the correct drivers! Success

This now leads me to the next challenge, programming the USB interface chip on the QS1R receiver board, currently being implemented here. I have discovered the default PID and VID for the device, and have discovered Phil’s VID & PID info, unfortunately today I’m still unsure how to get this data into the device. The device programmer mentioned above will not work (different manufacture), Cypress is the manufacture and I will uncover how to do this soon However looking through Phil’s LibUSB code, it would seem that this driver could solve the problem, as embedded are both the default and hardware specific PID’s & VID’s, so until I have the hardware here I can’t test this assumption. Either way it’s been a great learning opportunity

End of update

This is a very quick blog update, pointing readers to a fascinating story featured in Wired Magazine, here is the link: http://blog.wired.com/27bstroke6/2008/04/nsa-releases-se.html . It was 1943, and an engineer with Bell Telephone was working on one of the U.S. government’s most sensitive and important pieces of wartime machinery, a Bell Telephone model 131-B2. It was a top secret encrypted teletype terminal used by the Army and Navy to transmit wartime communications that could defy German and Japanese cryptanalysis. Then he noticed something odd….. you’ll have to read the rest yourself, I highly recommend the read

End of update.

This is a quick blog update, sharing a pdf Due to a number of requests I am sharing my current schematic for the Cumbrain implementation of Phil Covington’s - N8VB’s, fantastic Open Source QuickSilver receiver design. There are one or two very minor changes from Phil’s rev C design, and these changes are primarily around the VCXO I intend to use. Thanks again Phil for this futuristic and leading edge SDR design.

I am making slow progress on the board layout, but any progress in in the right direction

End of post.

This is a quick blog update, sharing progress on the PIC18F6722 development board. Following delivery I was keen to populate , as you can see from the picture below, it’ll looks pretty good.

There were a couple of small issues to overcome, namely, the DC socket, the RJ46 mechanical securing pins (hole slightly too small) and the missing solder resist on all feed throughs. None of these issues were difficult to rectify. The next stage of the dance is to produce some test code to

functionally check each board function, i.e. test the:

• LCD interface
• I2C 512 EEPROM A
• I2C 512 EEPROM B
• The three on board LED’s
• Com 1
• Com 2
• Button A

I’ll post the code, the HEX file and results in another update.

End of post.

This is a quick blog update, sharing some exciting news. My first ever professionally made PCB’s have arrived and they look fantastic Here’s a couple of pictures.

What this really means is that I now have confidence using Eagle to produce the gerber files for manufacture on future projects. Over the weekend I’ll populate one of these boards and functionally check performance. It was a great day today when the postman arrived!

End of post.

This blog update continues the discussion on VCXO’s. Following on from the last post….

Introducing Maximum VCXO Pull

VCXO designers approach the error allowance problem more directly. The method is to publish a value for maximum pull, instead of attempting to determine the safety margin for minimum pull.

The VCXO of the figure below provides +/-100ppm minimum GCR pull, and accommodates +/-39ppm worst case error by setting the maximum pull to +/-200ppm. In this design, the ‘internal’ error protecting minimum pull will exceed +/-139ppm, but can’t exceed the +/-200ppm outer pull limit.

Max/Min Pull Ratio Is The Key

Maximum pull, in a sence, governs the VCXO’s allowable safety margin. To what extent should the VCXO user be concerned with maximum pull?

Maximum pull, per se, is not the important issue. What’s important is the ratio of maximum pull to minimum pull. For a well designed part operating over the 0 deg to 70 deg temperature range, maximum/minimum pull ratio of 2:1 would signify a well designed VCXO. For wider temperature ranges, the VCXO designer might need a somewhat wider ratio.

Pull Ratio and F-V Linearity

A tight 2:1 ratio for maximum / minimum pull is more than a measure of VCXO part-to-part integrity. (And in turn, yield and cost). The constraint on the F-V curve imposed by the 2:1 ratio leaves very little wiggle room for curve nonlinearity. In other words, a VCXO with 2:1 pull ratio is very likely to exhibit excellent frequency-voltage linearity.

Best Straight Line Linearity

Historically, VCXO linearity has been expressed in terms of an average deviation from best straight line. Maximum deviation in the figure below (top) is approximately 12ppm, which is 6% of the -100 to +100 (200ppm) full scale pull range.

Linearity expressed in terms of average deviation can mask substantial (deltaF/deltaV) sensitivity variations. Different points along the F-V curve can have widely different deltaF/deltaV values.

Deviation Sensitivity Ratio

A more modern VCXO linearity specification, defined in terms of incremental deltaF/deltaV sensitivity, has direct bearing on the F-V transfer function. Referred to as Deviation Sensitivity Ratio, linearity of the VCXO’s frequency-voltage curve may be expressed as the ratio of the curve’s maximum deltaF/deltaV gradient to the minimum deltaF/deltaV gradient.

Designers of high performance phase locked loops typically require a deltaF/deltaV ratio below 2:1 to ensure transfer function uniformity.

Pull Voltage Selection.

VCXO’s are available with a range of control voltage choices. Awareness of the pros and cons of control voltage selection can reduce the end user component count (reduced cost and complexity).

Using a 3.3V VCXO to illustrate the point, users may specify a +/-100ppm pull VCXO for operation with control voltages of 0 to 2.5V or 0.5V to 2.5V

The figure below, two frequency-voltage diagrams highlight the difference. The key point lies in the different control voltages necessary to produce maximum negative frequency deviation.

In the top diagram, the user bears the cost and the complexity of extending control voltage down to zero. To achieve true zero control voltage, the control voltage circuit will likely involve rail-to-rail op amps, or D/A converters capable of developing 0V output.

Alternatively, the user can bypass the complexity of providing zero control voltage, and select a VCXO that develops full negative deviation with control voltage of 0.5V. In this instance the VCXO manufacture bears the cost of avoiding 0V by using a more sensitive (and costly) variactor diode

OK, over the last three blog posts we have gained an understanding of VCXO selection, and are better armed when selecting a sample from the catalogue

End of post.