Saturday, 7 January 2017

Nicely misinformed!

Well, it seems I was a little misinformed as to what the Pro Mini can do. Ive drafted a connection plan based on fewer I/O pins than it actually has!

Look very closely at the picture above (yes its robbed from a seller, but its the seller ive just ordered them from!). You might just make out two through-holes above the processor? Those are the A4 and A5 pins (unmarked!!!) and are used for the I2C. And again, lool at the bottom edge next to the reset button - three holes i'd not seen - A6, A7, GND!

Wonderful! This 33mm x 18mm board has all the pins I need, with the help of the I/O Expander IC, plus about four spare!

The I/O Expander and the RS232 Driver should sandwich to this board and make a nice compact controller module.

Im starting to think though, that it would make sense to treat the 'local' controller as essentially a dumb terminal - just reading inputs and reporting them, or sending outputs as directed. All the processing of the pin data into actual decimal frequency can be done with all the rest of the clever stuff up in the 'remote' unit, where the controller can be phyically bigger but also bigger in terms of SRAM and FLASH etc.

Update - I may have ballsed up with the Texas Instruments PCF8575 though! It might be a 5v device only! The Microchip MCP23017 though is 3v capable and about the same size and operation. But is a bit more expensive!

Edit - Doh! I can obtain the Microchip device as an experimental sample!

RT-320 Controller - More Hardware Options

After a bit of further thought and advice received, im coming to like another hardware option for the 'local' end of this project,

There is another Arduino, the Pro Mini, that is even smaller than the Nano, and, if the analogue pins are used as DIO, gives 20 I/O pins. Now, I need, if I also have the LOCK detect and AGC inputs, 30 I/O lines!

But heres the win - the Texas Instruments PCF8575 I2C 16-bit bidirectional port expander! 2 (or maybe 3, if the interupt is used) connections from the Mini, expands to 16 I/O lines. So, with 4(5) pins of the mini used for serial comms (RS232 and I2C), that leaves 15(16) plus 16 = 31(32)!

More than enough, and some spare!

Another two big advantages - both devices are 3v capable, and very small!
A disadvantage is that the Mini requires an off-board serial controller to connect it to the PC! But once programmed and working that is redundant anyway so isnt needed in the final working unit, its space being used for an RS232 driver instead!

Update - I think the Mini will actually only give me 16 available lines, plus 2 for Serial Comms. Might be a bit tight with just one expander! Perhaps only one or two spare pins!

A bit of work on the block diagram and it looks like the combination of a Pro Mini and a PCF8575 is the way to go! An RS232C SMD driver module to complete the set-up. The MOSFET needed to switch the Switches Vcc line can be a small single channel logic level shifter modified, or even a 2N7000 dead-bug connected to the Expander board. The AGC line for an S-meter, and the 2kHz LOCK tone, will input on a couple of Analogue pins.

RT-320 Controller - Major setback

Damn!

And it was all going so well!.

Yesterday, I 'presented' the Arduino Mega board to the RT-320 to gauge the fit - and it doesnt!

 
 
In the photo above, you can see where the board has to go, its in the space between the turret and the filters/PSU module. Essentially, the slot down the middle.
 
 
So its back to the drawing board.
 
 
On another note, the 2nd 24v SMPSU went back, and was refunded with no problem whatsoever. The seller, Makershut, was appolgetic and promised to discuss the issue with their supplier. All in all very pleased with their response.



So, how to deal with the RT-320 space issue? One idea im considering, whilst trying to stay with the Arduino route, is whether the space is sufficient to hold a pair of Nanos? Maybe side by side, or perhaps built as a sandwich? A Nano has 14 Digital I/O lines, and 8 Analogue. Two of the DIO pins are used for dedicated serial comms.

But, heres a trick! The Analogue pins can be used as ordinary digital pins! So thats 22 DIO lines available.

Now, for this project I need a bare minimum of 20 lines, thats if I only read and write the sub-MHz. In order to read the 10 and 1MHz switches as well, I need 26 lines (one of which controls switching the supply line). Perhaps add an Analogue input to read the AGC line to provide a signal meter as well - 27 lines. A minimum 2, probably 4 lines for serial comms, and then another 2 lines for I2C comms between the two Nanos...

...getting complicated! But im sure the Nanos and the comms are all capable of operating far faster than a human can change a setting.

I believe I can use just 2 lines for RS232 (TxD, RxD and GND), so 2 DIO pins for the Master Nano comms (2x RS232, 2x Analogue [A4,A5] I2C). That leaves 12 DIO lines on the Master. Two Analogue lines for I2C on the Slave Nano leaves me 14 DIO lines. If we figure that the most likely lines to change rapidly are those of the 100Hz and 1kHz switches, thats 9 DIO lines. This means that the I2C, RS232, 100Hz, 1kHz, and the switch Vcc control, can all be done on the Master Nano, without having to resort to using any more Analogue pins than the I2C. The AGC input can go to the Master A0 input, and the LOCK tone to A1. This means that the Slave Nano, with pins A4 and A5 used for I2C comms to the master, would have the 10kHz, 100kHz, and 10MHz switches on its remaining DIO lines, with four of its Analogue lines repurposed as DIO to read the 1MHz switch. This would leave 4 spare analogue lines on the Master, and 2 spare analogue on the Slave.

Of course, all this relies on the available space being able to fit the two boards!

If it can, then it is certain that I will need an experienced programmer to write the software!

The Remote module, if using a Nano, will fit all basic, and some advanced, functions on the DIO pins - A4, A5 I2C to an EEPROM for frequency memories/split/A-B VFO etc, D0, D1 for RS232, 6 DIO lines for the LCD, and 2 DIO for a rotory encoder. The LOC/REM switch, UP, DWN, SELect, VFO/MEM, and SPLIT/A-B VFO functions can share DIO and some Analogue pins used as DIO.





Wednesday, 4 January 2017

Clansman Arduino Code - Starting to feel a bit lost

Since I last posted about this project, the Arduino forum user who has been providing me with assistance with the code has advanced the software to beyond just reading the frequency selection switches, to beginning to form the code that will correct the readings and send back an actual frequency reading.

But this now puts me in a bit of a fix - Im rapidly getting out of my depth! My problem is that although I can code very simple programs, put words on an LCD, flash LEDs etc, and can to a point understand what a program is doing and roughly how, much of the actual code needed, and indeed the maths, is very likely beyond me.

I think the time is nearly upon me when I need to find someone with whom to split the task - me doing the hardware, specifying the requirements of the code, testing it on a real radio, and of course taking the risks regarding electrical failures and circuit damage; and the other person writing the code as needed, with the added safety of doing so in a simulated, breadboard environment.

Ive now tested all the DS18B20s received today and they are all working. Ive also just added the MOSFET driver to the Dewheater project, and based on its onboard 'signal' LED, which changes brightness depending what percentage of heater on time the system is demanding. This is exactly what I would expect of an LED being fed a PWM signal, so all looks good.

Dew Heater Controller - A bit further

I came home today after a trip to the post office (to send back the SMPSU) and a walk in the woods to photograph fungi (where I found a musket ball!), to a pile of packets on the doormat. These all contained various items for Arduino projects, including two more Nanos, and a barometric pressure sensor.

Most importantly, these packets also contained both the 'raw' TO92 DS18B20 temperature sensors, but also the housed and wired sensor. Which meant that if all was well I could crack on with the Dew Heater Controller.

First, I uploaded the 'Blink' test sketch to each of the new Nanos to make sure they worked. Both ok. I then rebuilt the Dew Heater Controller on the breadboard, and added one of the new DS18s - Yay! It works!


In the photo above, ive changed the sensor to the wired one, which luckily also works. You can see that now the controller can measure the 'lens' temperature (shown as 16°C) and also how much higher or lower this is than the dewpoint (in this case its 10°C above the dewpoint). The bargraph shows the percentage 'ON' time required by the heater strip. As this setup on the bench is well above the required Dewpoint + 5°C, there is no need for the heater to be on and so no indication on the bargraph. I have changed the temperatures a bit to make it think the heater is needed, and the bargraph does indeed change. You can also see that the display says 'Heater 1'. The code in this version is 3 channel.

Next step with this is to add the MOSFET driver and the heater band, and if all is well, proceed to boxing it up ready for use!

Tuesday, 3 January 2017

Getting seriously pissed off with SMPSU suppliers!

 After the 24v 3A SMPSU from China that blew up, I decided instead to obtain one from a UK supplier, in this case trading under the name 'Makershut',

Well, it was over twice the originals price, and on arrival this morning (give them credit it was sent quickly and well packed), two problems were immediately apparent. First, its twice the damn physical size! Ok, I can probably live with that,

What I cannot and will not accept however, is any electrical safety issues. And this has them. A cursory look through the ventilation holes revealed A) one of the transistors tabs that should be secured to the heatsinking of the case is not. Its bracket is present but not positioned. And B) there are numerous blobs of solder on the silkscreen/component side of the PCB. Just one of these coming loose could not only short and destroy the unit, but could cause a fire.

The photos below are not the sharpest, but they do show the faults. The reason for them not being SLR quality is that in order not to have to break the warranty seals, these were taken using an endoscope.


Solder spall by capacitor CY3 (potentially a class Y capacitor)

Very poor fixing bracket
Solder spall by C19


Transistor tab not even close to chassis!


No. Im not at all happy.

I have started the return process. I expect to receive a full refund including the shipping.

Edit - I have received a prepaid return label so this will be going back. 
As these units do not have a serial number. I have taken the liberty of adding an identifying mark to it in such a way as to be able to identify the module as being the one I sent back. I have photographed the mark but will not post the photo for obvious reasons! 

On a slightly lighter note, thanks to help on the Arduino forums (I will give full credit if these chaps agree) I now have some better understanding of how to read the frequency dials of the RT-320, including some clever use of arrays to make the code more compact. Im now trying to get my head around the section of the code that actually reads the dials and returns their values. It is these returned values that I will have to manipulate to obtain the equivalent dial settings.

This section of code initially wouldnt compile. A bit of head scratching and a few trial changes, and I managed to actually debug it! It seems a command for reading the pins was written incorrectly. Its now doing as expected - reading all the pins, in their appropriate 'dial' groups, and returning the expected value for each of 255. This being as they are all pulled up to Vcc as I havent yet actually connected any switches!

Sunday, 1 January 2017

Clansman Remote Control - Arduino Basics

After formatting and re-installing Windows on the laptop last night, I now have a working driver for the COM ports that works with the Arduino IDE, and am able to crack on and start learning to make these amazingly useful little controllers do what I want them to, which is, at this stage, to read switches.

The example sketch code provided by members of the Arduino forum is working perfectly. This has given me a great boost and got me off the ground. Bits of previous programming experience are starting to surface from the depths of my addled Tyke memory, so im now making slight changes to this code and seeing how it responds. I started with the example, set up for a 5-bit input. Im now modifying it to handle 2x 4-bit inputs, which is the equivalent to reading the 1MHz and 1kHz switches on the RT-320 (the 10MHz is 2-bit, 100kHz, 10kHz and 100Hz are 5-bit).

The results from the code are the decimal equivalent to the binary inputs on the pins. But the switches themselves seem to follow absolutely no sensible code, its cerainly not normal binary or BCD, doesnt even seem to be any form of Grey Code!. So the next step will be to find a way of carrying out a conversion step.

5-bit test example on Arduino Mega2560

A further problem that needs solving with the Clansman control system is that the Clansman logic is 3v but the Arduinos are 5v. To this end, I have some MOSFET based level changers on order. These use SMT 2N7000's and are a rather simple affair

This is interesting, as one of these could easily be repurposed (and theres four on each module) to be the control switch for the 3v line to the frequency selection switches, which will disconnect them when the controller is in 'remote' mode and controlling the synthesiser.

New Year

Well, the changeover to 2017 and the insertion of a leap second, widely anticipated to cause caos to NTP servers and GPS timing and frequency references passed with exceptional understatement.

I had hoped to get the very basics of a sketch working for the Arduino to read a DIL switch, as a substitute for the Clansman PRC320s frequency selector switches, to allow me to work out a technique to convert the '320s truth table into something I can send to the controller. For this end im grateful to members of the Arduino forum for help with the C++ code. Sadly, for some reason I couldnt get the USB driver to work on the laptop! So testing that will now have to wait.

The laptop in question was Sams old one which ive just acquired. It was running rather slow, so since I couldnt get any further with the Arduinos, I decided to give it a complete fresh start, format the hard drive and re-install Windows 7. That all went nicely to plan. Trouble is, Its now a stand alone machine - until I can get the drivers on it for the Ethernet and WiFi modules!

Friday, 30 December 2016

Stuff

Cant think of a title for this post. The failed SMPSU has been refunded. No actual communication from the seller (apparently the sellers proper trading name is 'LeadCoo Ltd'), but a very prompt refund with no hassle.

Sadly, the cost of these supplies has over doubled! So ive ordered a replacement from a UK based (allegedly) seller. Ive also had to order more nut rivets for the mounting, and replacement fuses, as im all but out of them!

The IR remote control tester works nicely, but rather than continue with that now and try to fathom out a way to include 6v worth of battery and a 5v regulator into a 1inch mint tin, ive decided to instead power it from USB! To this end, a bit of shopping around on ebay found me ten micro-USB 'break-out' boards for a quid. These simply give you four PCB through holes on a 0.1" pitch, intended of course for SIL headers. But will allow simple circuits like this to be build dead-bug on the board.

Ive also finally got the box for the Theremin coming. Again that has proved to be far from cheap! But with any luck that will be another project complete and finished with soon.

Thursday, 29 December 2016

Infrared Remote Control Tester

Two things ive been pondering recently - how to test some potentially dicky TV remote controls, and what to do with a number of nice little metal mint tins I have,

well clearly the obvious thing is to build a little IR remote control tester!

I have some salvaged IR receiver modules amongst my junk boxes. It seems from what I can work out that these generally have an open collector output and run nicely on 3-5v, so it should be little more complex than giving it a suitable supply, and connecting a visible light LED to the output pin.

If it will work on 3v or less then a lithium CR2032 coin cell should power it for a good long while at the sort of very intermittent usage it will get, but it would be a very handy gadget to have.

To the workshop!

Well, I eventually found the IR receiver modules, in the box full of LEDs! I picked two out, one of which is a TSOP1738, and since this worked first time I haven't tried the other one.


Thats the best photo your getting, so deal with it! The circuit is so ridiculously simple for something so useful. A final version will need a few more parts to deal with the voltage requirement, sadly it doesnt work at 3v, so a pair of 3v coin cells and something to regulate it down to 5v will be needed. Probably a simple resistor and Zener diode will do. But other than the power supply, there really is nothing more to it than the IR receiver module, an LED and a 1K series resistor!

Ive tested this with all the remote controls I have to hand. Its interesting that some have much faster data rates than others. And as suspected, the remote for an Amazon Fire TV stick isnt IR!