IOT for the Small Block - Part 1

There has been much written about IOT (Internet of Things..... devices that we wouldn't initially think of as computers connected to the internet.... smart thermometers, refrigerators, coffee machines, etc) and while there are some interesting, fun and possibly limited utility applications of IOT for the average apartment dweller, for those of us that live on lifestyle blocks IOT devices really can help.

This is the first in a series of posts describing how I have used an IOT device (a little computer really) that connects to my block wide WIFI network and does really useful things.

The basis for all my IOT devices to date is the BlockTECH WIFI Controller board.  

 

Assembled BlockTECH WIFI Controller v2

On my block I use the BlockTECH WIFI Controller for the following:

  • Monitoring inputs and triggering outputs when the input state changes (a smart burgler alarm - great for the workshop).
  • Automatic monitoring on/off at configured times (no need to remember when to enable the alarm).
  • Manual output control from my smart phone (switching off the electric fence before I walk out of the house so the horses, always happy to see me and their breakfast don't zap themselves).
  • Monitor bore and pump running state and chart the results (find out which neighbor has the leak that causes the shared bore to run 24 hours a day).

The BlockTECH WIFI Controller is modular and can be assembled with only the components required for the task at hand.  

  • If only monitoring then exclude the relays and drivers.
  • If you only want to control the electric fence or the front gates from your smart phone then exclude the input circuits and install a single relay.  
  • If you want to monitoring the bore and pump then exclude the relays and use a single input.

I will write a seperate posts for each showing how the board is assembled and the software configured.

 

BlockTECH WIFI Controller v3 Schematic

 

 

MS11-JP MOS Memory SN#1958348/78

The MS11-JP (M7847-DJ) is a MOS memory board for Unibus PDP11's. In the PDP11/04 I am restoring there are two fully populated boards, each with 32K words of dynamic memory.... and neither board works when accessed from the front panel.

The first board I worked on is SN#1958348/78.

Using the front panel the board did respond to read and write requests to RAM in the assigned memory block but reading data did not show the value that had just been written.  This behaviour was consistent at any address I tested.

The voltages (+5v, -5v and +12v) were correct on the dynamic RAM chips so I used a logic probe to check for activity on the dynamic RAM chips with both no front panel activity and when reading and writing to memory.  

When not attempting to access the memory using the front panel there was activity on CAS (Column Address Strobe) and RAS (Row Address Strobe) which suggested that the refresh circuit was doing something and may even be working.

Attempting to write to memory from the front panel showed activity on WR (Write) which was also expected.

What I did not see was activity on CS (Chip Select).  If CS does not go low then the chips are not selected which means the write does nothing and the read shows random data from the Unibus.

 

Working backwards from CS through the schematic shows that CS is generated by a 7440 NAND Buffer (E114).  I could see activity on the input (pins 9,10,12 and 13) but no activity on output (pin 8).

Replacing E114 with a "new" 7440 sourced from eBay (with what appears to be a 1973 date code) fixed the problem.  It is now possible to write data to RAM and read it back.  I haven't done a full RAM test yet and can't do this until I get the processor board operational.  

These notes are written with the benefit of having solved the problem. The MS11 memory board is a lot more complex than I am used to in microcomputers.  It has it's own refresh circuit independant of the processor that identifies and gives priority to processor requests.  There are also circuits for address mapping (configurable) and Unibus bus interfacing so a lot of time was spent trying to understand how the board worked.  The EK-MS11E-OP-001_Oct76 and MP00019_1104_EngrDrws_Feb78 documents were invaluable in understanding the board and eventually fixing it.

The other MS11 does not exhibit the same symptoms.  Attempts to access the board give a Bus Error.  Initial indications are that the issue is in the refresh generation circuit.  We will see.....

 

 

Kaypro 4/83 Floppy Disk Woes.....

I have written in earlier posts of my project to interface the FreHD hard disk emulator to my Kaypro 4/83.  

The standard Kaypro ROM does not include hard disk support so a third party ROM is required, the most common being KayPlus from MicroCode Consulting or the Advent TurboROM from Plu*Perfect Systems.  

The initial project work was done using KayPlus because there was no known source for the Advent TurboROM compatible with the Kaypro 4/83 (the version for the 4/84 was readily available but the two machines are sufficiently different that it can not be used).  The KayPlus ROM worked but there were a few odd behaviours running some CP/M applications that needed further investigation.

In May 2014 a Kaypro II was purchased from eBay by phorgen on the Vintage Computer Forum that included the rare '83 version of the Advent TurboROM and phogren was generous enough to share a copy of the ROM to help with this project.

Between June and September 2014 the Kaypro sat untouched while "real life" got in the way and I finally got back to it on October.

Working with FrankS (also of Vintage Computer Forum fame) we got the 4/83 + FreHD to boot using the Advent TurboROM (details will be included in a future post) but I had problems reading and writing floppy disks.  

The initial symptoms where that Advent CP/M would not recognize standard Kaypro format floppy disks.  Nor would it read a disk that it just formatted.  

My initial thoughts were that the Advent ROM was not compatible in some way with the KayPro 4/83 so I swapped back to the standard Kaypro ROM.  That wouldn't boot either.

Now suspecting the floppy drive I tried a number of different drives and none would read a disk.  

Finally after closely watching the drive while formatting a new disk I realized that the heads were not stepping even though the formatting program was counting up the tracks.

Given that track stepping is directly controlled by the Western Digital WD-1793 Floppy Disk controller, I replaced the Kaypro WD-1793 with a known good part from a TRS-80 Model 3

The known good WD-1793 worked fine in the Kaypro which was a big relief.  Not sure if it was old age or caused by my handling of the Kaypro PCB but at least now I knew what to replace.

On eBay I learned a few things about the WD-1793 (or FD-1793).

  • The WD-1793 (or FD-1793) is expensive.  
  • They are also frequently described as "collectible" or "super rare" which doesn't inspire confidence that a working part will be had for the money.  
  • The Soviets made a compatible part called a KR1818VG93.  This was even more expensive and collectible.  They may also be metric pin spacing so even if a working part was obtained it wouldn't fit well into a Kaypro socket.
  • Mitsubishi made a compatible part called a M5W1793 which were readily available as NOS parts from China at a much better price. 

The M5W1793 seller (no relationship.... just a satisfied customer) had good eBay feedback so I ordered 2 units hoping they would be genuine.

Two weeks later (very quick.... normally it takes 3-4 weeks from China to New Zealand) and the parts had arrived when installed in the Kaypro worked perfectly.  

 

 

The Model 3 can have it's FD-1793 back.

 

 

GPS Connection to Hans Summers Ultimate 3 QRSS Kit

A few years back I built a QRSS transmitter (for slow morse and WSPR) based on a recycled DLink DSL-502T router running OpenWRT and connected to an Si570 DDS module. (http://www.quicktrip.co.nz/jaqblog/home/44-si570qrss)

This worked well for a while but eventually the DSL-502T failed and would no longer connect to the network.  Not great for a time synchronized QRSS transmitter that relied on NTP service.

The replacement is a Hans Summers Ultimate 3 QRSS kit.  (http://www.hanssummers.com/ultimate3.html).  The Ultimate 3 is a combination microcontroller and AD9850 DDS module that if connected to a GPS providing 1PPS and $GPRMC NMEA sentences will generate time synchronized messages in a number of formats with no requirement for network connectivity.

In my parts bin I had several Ashtech g8 GPS modules.  The Ashtech g8 is a late 1990's GPS module designed for integration into OEM equipment.  I picked up a several at an Amateur Radio junk sale a few years back and hadn't really put them to use.

The g8 meets the requirements for the Ultimate 3 by providing the required 1PPS signal and $GPRMC sentence.  Unfortunately the default configuration on power up does not send $GPRMC and instead sends $GPGGA and $GPVTG at 4800 baud.  The startup configuration can be changed by connecting via the serial interface, changing the configuration and saving to backup memory but to retain this (and the GPS almanac for fast power on) when the power is cycled requires a 2.7v-5.5v power source on the V_BACKUP line.

With fast startup not critical for this application and not wanting to worry about backup batteries going flat, I decided to go with a different approach and use a microcontroller to reconfigure the g8 on power up.  

With a number of other applications for GPS in the shack I also decided to buffer the 1PPS and Serial outputs of the g8 and make these available for use other than the Ultimate 3.  This is done using a standard 74LS buffer.  More on this in the next article.

The GPS configuration is handled by an AVR ATTiny2313A with the code written in C using AVRStudio with the compiled code using 508 bytes (28%) of the available flash memory.

The approach is as follows:

  • Wait 5 seconds on startup for things to settle
  • Start receiving serial data from the GPS at 4800 baud looking for 0x0D, 0x0A,$ indicating the GPS is in the default configuration sending data at 4800 baud
  • Configure the GPS to send data at 9600 baud using the command $PASHS,SPD,A,5
  • Start receiving serial data from the GPS at 9600 baud looking for 0x0D, 0x0A,$ indicating the GPS speed configuration command worked correctly
  • Configure the GPS to stop sending $GPGGA and $GPVYG (actually stop all data) using the command $PASHS,NME,ALL,A,OFF
  • Configure the GPS to start sending $GPRMC using the command $PASHS,NME,RMC,A,ON
  • Sleep

I have included the code here should it be useful for anyone wanting to perform similar configuration but note that your GPS may require different commands.

 

ATTiny2313A and 74LS buffer.  The ATTiny2313A can be run from an internal oscillator with no external crystal and capacitors required but they were already on the board after an aborted attempt to get C code to run correctly on old AT90S2313 parts from the junk box.  The LED's are for debugging and indicate the current state machine step.

Alternate view showing the Ultimate 3 and the g8 GPS module.

 


Page 6 of 30

Powered by Easytagcloud v2.1

Contact Andrew Quinn

jaquinn@ihug.co.nz http://twitter.com/jaquinn