After a lot of searching, the correct case for the EPE Theremin was located, in Australia! Thanks to Terry VK5TM, this was shipped at not inconsiderable cost over to me here in the UK. So, you can imagine im rather nervous about actually working the box!
But, clearly a brand new box is no use without the necessary holes drilled into it! By far the hardest part of this has been mounting the Volume Antenna plate. This required not just the holes for the bolts, but a considerable depth of side wall material filing away. Although the plate is 1mm thick, this cut-out needed to be rather more, due to the small but significant bend radius. It was also necessary to remove the lip from the lid as well, which was done by shaving it away with a sharp blade.
The photo below shows the Volume Antenna plate and the Pitch Antenna fitted. For the pitch antenna, as well as the bolt hole, a semicircular cutout needed to be filed out of the lid.
And here it is with the lid fitted,along with three of the four external controls/connectors.
The power connector is a 3.5mm Mono jack, in lieu of a DC Barrel connector. The Phono socket is the Line Out connection. The switch is, of course, on/off. Missing from this photo is the volume control pot which will mount in the left hand side hole.
Whats left to do now is wire these up to the PCB, and secure the PCB to the stand-off pillars it rests on. I can then test and align it as needed.
I am unsure yet whether to drill the holes in the lid for the sound and mount the loudspeaker, or whether to leave that for its owner to complete!
Musings and adventures in amateur radio, electronics home construction, military comms equipment, charity long distance walking, life and career
Tuesday, 31 January 2017
Sunday, 29 January 2017
QRM and SOIC
Following my discovery of the actual source of the interference on 2m mobile, I found a few moments yesterday to install the ferrites.
A pair of snap-on TDK beads at the camera end of the cable made no difference. So definately an issue with the switching regulator. So it was off with the glove box, on a cold and rather wet afternoon. A couple of beads installed on both the output and 12v feed cable of the regulator module, and the QRM has gone.
Its quite surprising how many signals this was masking! A few quick air tests with M1BBV proved everything to be working well again.
The development of the hardware for the Clansman Remote project is coming, hopefully, to a conclusion. I have Arduino Pro Mini's which will physically fit the space and will operate at 3v. I have 3v I/O expanders, and I have an advanced RS232 line driver coming. However, the I/O expanders and the Line Drivers are SMD, SOIC28 and SSOP28 respectively, and so im now waiting on delivery of 'break-out' PCBs on which to mount these!
In the meantime, the box for the Theremin has finally been acquired! So I hope to get that finished once and for all very soon!
A pair of snap-on TDK beads at the camera end of the cable made no difference. So definately an issue with the switching regulator. So it was off with the glove box, on a cold and rather wet afternoon. A couple of beads installed on both the output and 12v feed cable of the regulator module, and the QRM has gone.
Its quite surprising how many signals this was masking! A few quick air tests with M1BBV proved everything to be working well again.
The development of the hardware for the Clansman Remote project is coming, hopefully, to a conclusion. I have Arduino Pro Mini's which will physically fit the space and will operate at 3v. I have 3v I/O expanders, and I have an advanced RS232 line driver coming. However, the I/O expanders and the Line Drivers are SMD, SOIC28 and SSOP28 respectively, and so im now waiting on delivery of 'break-out' PCBs on which to mount these!
In the meantime, the box for the Theremin has finally been acquired! So I hope to get that finished once and for all very soon!
Friday, 27 January 2017
Bloody Interference
Well ive finally tracked down the odd 'silent' interference affecting 2m when im mobile -
Its the supply to the front dash camera!
I suppose I should have realised, it is after all only a cheap Chinese USB switching regulator. But, the way the level and frequency of the interference changed during a journey had me thinking it was something else.
It came to light that this was the cause after some experimentation over lunch. No interference with the camera off but ignition on (regulator powered but off load); no interference with the camera on but on its own battery (regulator not powered); but ignition on and camera on (regulator on load) = QRM.
Ive just dug out a bag of snap-on ferrite beads, TDK type ZCAT1325-0530. From what I can interpret of the datasheets, these are intended for EMC filtering on USB cables. Ive no idea if these will provide enough impedance, but they are all I have so i'll have to try them.
Its the supply to the front dash camera!
I suppose I should have realised, it is after all only a cheap Chinese USB switching regulator. But, the way the level and frequency of the interference changed during a journey had me thinking it was something else.
It came to light that this was the cause after some experimentation over lunch. No interference with the camera off but ignition on (regulator powered but off load); no interference with the camera on but on its own battery (regulator not powered); but ignition on and camera on (regulator on load) = QRM.
Ive just dug out a bag of snap-on ferrite beads, TDK type ZCAT1325-0530. From what I can interpret of the datasheets, these are intended for EMC filtering on USB cables. Ive no idea if these will provide enough impedance, but they are all I have so i'll have to try them.
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!
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.
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!
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.
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.
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!
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.
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!
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.
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.
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!
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!
Subscribe to:
Posts (Atom)