499A Weblog

Friday, July 27, 2001
This log is to update the status of the buffer board, merging unit and sinewave generator hardware. The following describes the hardware modifications, known hardware bugs and the solutions.

Hardware Mod: GPIO 15 on BUFFER BOARD jumpered to U blah.blah . U blah.blah jumpered to Jblah.blah (DB25 connector).

Reason: The GPIO signal is used to frame data samples when they are burst to the NIDAQ. The above mod makes the signal available on an unused pin on J blah that connects to the NIDAQ via a straight through cable and a DB25 to NIDAQ 64 PIN adapter.


Cause: Merging Unit Frame Sync pulse (bit wide pulse) has too fast edges. The frame is put onto backplane differentially, but the slew reate is too great and is dumping too much energy onto the backplane too fast (EMI). Affecting neighbouring signals.

Solution: The differential frame signals (+ and -) are driven through serial resistors. The serial resistors were intially set to 10 Ohms. This was increased to 100 Ohms in a hope to increase the RC time constant for the frame edges. This solved the problem and the glitch either does not happpen at all anymore, or is much much less frequent than previous (i.e. possible once every 0.2 seconds may see a glitch, but this may not be the same glitch). 91 Ohms was placed in series with the original 10 Ohms. The 91 Ohm resistors were soldered across the frame jumpers such that they could be shorted if they were of no use.

This log is to update the status of the buffer board, merging unit and sinewave generator software. As of today, the DSP software is finalized for each board:

Buffer Board

The buffer board "rips" apart the IEC 60044-8 packet, extracts data, performs error detection and stores 0.2 seconds worth of each phase V and I (6*960 samples). The buffer board uses the ESSI Receive Data Interrupt to unpack the packet. When 16 bits are valid in the ESSI Receive Data Register, the interrupt occurs. The Start character of the packet is looked for. If the word is not START_CHAR, then the word is dropped and the handler returns. Once START_CHAR is found, two counters find the metering data and CRC. At this time, other more "static" data is not saved to file. Receiving and analyzing the "static" data is trivial.

When 0.2 seconds of data is accumulated, the Buffer Board bursts the record out to the NIDAQ via th 16 bit parallel port on the board. 5760 samples takes about 1.3 ms to burst to the PC.

LEDS are updated in the main loop (Lowest Priority).

Merging Unit

The merging unit receives 6 channels of data ( 3 phase voltage and current) on a TDM bus. The bit and sampling rate are proprietary to NxtPhase. The NxtPhase sampling rate is greater than the Specified IEC 60044-8 output sampling rate (4800 Hz). Therefore, the merging unit performs a running average on each channel. This averages samples and divides the sampling rate by the number of elements in each average.

To packetize the average samples, the merging unit uses two "packet areas". At any one time, only one packet area is VALID and the other is BUSY. A BUSY packet is being transmitted at the specified standard 2.5Mbps. A VALID packet is available for the averaged data samples to be written to, as well as CRC and any other information that is not "static" between packets. A VALID packet is completed and is ready for transmission just before the current BUSY packet is completely sent. This way, the Merging Unit is able to output a continous stream as specified by IEC 60044-8.

To implement the receive of the NxtPhase channels on a TDM bus and the send of the IEC 60044-8 serial stream, ESSI0 and ESSI1 on the Motorola 56303 DSP were used. ESSI 1 and ESSI 0 interrupts are set at the same priority level so that all interrupt requests are stacked in order of appearance. This way, the receive of one serial stream or the transmit of another does not push out the other interrupt to the extent that an under or over run occurs.

LEDS are update in the main loop (lowest Priority).

SineWave Generator

SineWave Generator as before with the following correcitons:
Fixed a bug that affected the sinusoids
Added dynamic phase angle addition to phase C current for demonstration

Monday, July 23, 2001
Darrin has finished the merging unit and the buffer board decoding software. Verification remains to be done to rid the system of a few minor bugs. The LED software still needs to be written.

Friday, July 20, 2001
Completed an FFT option for each of the six input signals in the DIPM GUI. There are now two windows, one for time and one for freq. It has proved difficult to plot the actual frequency, so the FFT is just a rough estimate of harmonics in the signal.

Wednesday, July 18, 2001
Tested the DPMI GUI with Aloysius's Marr Meter 2, which features a file dump to a .dat file. However, Aloysius's program requests a "replace file" after ever retrieve. Once Aloysius has this fixed, the GUI should be ready except for a RMS display and maybe an FFT for each signal.

Tuesday, July 17, 2001
Brad completed a prelim. version of the Excel VB Script that will read and plot the file that is dumped to the PC by Aloysius's 'Marr Meter'. It is called 'DIPM GUI' and now needs to be tested with the live file dump. There is quite a refresh lag encountered with plotting the data, so the refresh is currently set to 1 second. This may be alright, but this is only with a single plot being refreshed with 2 dummy input signals. It is planned to display all six plots seperate and then some calculations involving them all (FFT's, RMS power, etc.) The refresh may need to be set back even more.

Friday, July 13, 2001
Dated From July 10th, 2001
Marcie and Brad installed the NIDAQ card in Brads computer. It worked as hoped. After many unsuccessful attempts at located a copy of Matlab to create the GUI, Marcie and Brad decided it necessary to simply write the display software as an excel VB Script.

Darrin and Brad connected the NIDAQ to the preliminary buffer board and were able to acquire samples. However, the software created by Aloysius had a few bugs. Here's the email sent by Darrin to Aloysius...

Questions and Problems regarding Marr Meter software:

Question: Why are there 7 columns in the "Output Array"?? We are sending 6 interleaved channels.

Question: Does the panel refresh itself after each burst (bursts spaced 0.2 seconds apart) or does the display refresh at a slower rate.

Problem: Somewhere along the way, we got our ports backwards. Can you swap the software so that Port A on the DIO are the MSBs and port B is the LSBs? We can do it, but the physical rewiring would be very difficult. I suspect this is quite easy for you to do?

Besides the backwards ports, everything looks good. Cannot tell much more until we have a file dump. We are ready to have the data dumped to file after every burst (file is rewritten, is ASCII format, each channel is a column of 960 samples (960*6 = 5760) ).

Thanks Aloysius


Dated from July 4th, 2001
Darrin and Brad talked to Dr. Aaron Gulliver regarding the CRC error codes in the IEC standard. A method of encoding and decoding on our DSP was decided upon. A satisfactory algorithm was designed.

Sunday, July 01, 2001
Darrin and Brad reorganized the memory for the Buffer Board so that both the X and Y contribute 2880 samples spaces to the buffer process. The Buffer is now set for a 0.2sec buffer then transmit on the parallel port.

Wednesday, June 27, 2001
The sinusoid generator is complete, and a new LED pattern has been designed by Darrin and Marcie. Yesterday, Darrin and Marcie laid out the plan for the buffer board (between the MU and the DAQ at the meter). There were some hangups with the buffer board, but it has been decided (after some discussion and Darrin looking at the debug board in depth) that we will have a buffer of 6K (0.2 seconds on the meter) as long as our program size stays under 1K.
Email from Darrin...
We forgot about Y data memory. This doubles our capacity. ALSO, I read the fine print on the Memory Map, and X and Y data memory can both steal 1K from Program. In total there is 8K of memory. Check out the attatched picture to see the possible configurations.

Therefore, (if we keep program memory for the buffer down to 1k ($400)) then we have 6K of data to work with. Gonna mean we will have to have tight code, but should be easy to keep P down.

6K = 6144 memory spaces

so 4800*0.2*6 = 5760 memory spaces

SOOO, we can take a time record of 0.2 seconds, distributed throughout X and Y data. Leaves us with 384 spaces for general purpose use.

Sounds good right? Trick is to keep P down. Right now, bf is at $39B, but with alot of shit we don't need. I also noticed that P can be increased to 2K if the "instruction cache" is not used.

We started programming the interrupt handler for the 4.8kHz using dummy data (since the merging unit has not been designed yet). We've decided to use dummy data instead of working on the MU since Aloysius should be sending us the DAQ software soon, and we would like to test it.

Also, Brad and determined that it is not possible to set up a copy of Matlab without Nxtphase allowing us access to their license server.

Monday, June 25, 2001
Darrin, Marcie and Brad went to Lab to finish Digital Sinusoid generator. Completed generation of 6 digital sinusoids sampled at 10 microseconds (100kHz). Each sample of each sinusoid (V and I 3-Phase) was sent out on TDM bus.

Tried to insert "running" LEDS to give user operation. Got to point where LEDS are refreshed at proper rate, but not refreshed with proper value. Problem with FLASH_COUNTER being modified outside its specific code.

Darrin went to lab at 9:30 P.M. to figure out the LED bug. Found a LARGE bug with the Transmit Data Interrupt. Were clearing register r2 to 0 after every frame, but should have been setting r2 to SINE_BASE after every frame. Explains the FLASH_COUNTER being modified. After this was corrected, the LEDS worked perfectly. Found this bug in about 2 minutes, so started Pre-Buffer board to test Aloysius's LabView file once it comes. Generated an interrupt (IRQB) at 4.8kHz rate to simulate the IEC 60044-8 standard sampling rate (80*fr = 80*60Hz).

Wednesday, June 20, 2001
Darrin, Marcie, Brad met in A 317 for 3+ hours to work on sinusoid generation. Ended up spending all of time debugging ESSI board to board communication. Found 1 hardware bug, 2 software bugs. Hardware problem is connector 6 (counting from left side of rack) has shorted pins affecting the ESSI serial clock. WE SHOULD NOT USE CONNECTOR 6. Software bugs were found and corrected. The ESSI communication is now error free and the peripheral is ready for 14.4MHz transmission of 6 sinusoids on 6 channel TDM bus to the Merging Unit.

(This post is 2 days late)
Researched ESSI's ability to transmit continuous data stream. Researched receivers ability to recieve asynchronously. Found application manual and downloaded it. It seems that ESSI will be able to transmit continuous on one end and receive asynchronously on the other. Unsure yet if receiver clock = transmitter clock (synchronous clock, asynchronous ESSI mode, or if receiver clock = n*transmit clock where n is positive integer. Not necessary to send Frame Sync for asynchronous mode.
It would make sense that receiver clock is transmit clock, and receives on the opposite edge that the data is clocked out. Makes sense because the clock is actually sent with the data stream (Manchester Encoding), and is therefore usable on the "meter" end.

Sunday, June 17, 2001
A CD containing the Suite 56 from Motorola was burned. The suite was also installed on Brad's laptop and the lab computer at the ELW. Marcie, Darrin, and Brad went to the lab to setup the hardware and test the setup including the lab PC, 100 MHz digital oscilloscope, debug boards and backplane. A first bit of work was done on the creation of the 3 voltage and 3 current test waveforms, with the serial IO (I forget the designation) parameters decided. There is a paper including the notes taken during our discussion that will be appended to our log or webpage in the next little while.

Saturday, June 16, 2001
Went back to A317 (old ELEC 320 Lab) after my interview with spectrum. Had to figure out how to get Suite56 from Motorola before Sunday so we could do some work. Phoned Michael Wand at NxtPhase and had him find the correct Suite56. It was 74Mbytes. How to transfer? Phoned Brad from the lab..but he was not home. Got Emillie and I had her find and boot Brad's FTP server. Tried to phone Marcie because Emillie did not know the name of FTP daemon. Marcie was not home. Phoned Emillie back. Emillie found the FTP software and started it. She tried to remember Brad's password., but couldn't so emillie made a new profile. I logged onto Brad's computer with new profile, but couldn't upload files as emillie did not give new profile any permissions. Phoned Emillie back. She was nearly attatcked by bunny rabbits for her apples. She set the correct permisions. Still couldn't upload, cause I was logged in while profile was changed. Phoned Emillie back. Set the permissions RIGHT this time (Emillie probably getting annoyed). Uploaded test file to Brad's computer. Phoned Michael at NxtPhase. Stepped Michael through the FTP and had him start upload of WIN56300.exe to Brad's PC. Don't know whatelse happened. At the same time, talked to David Romalo. They have Matlab 6 and will send (probably via padded envelope and courier or mail) software for project. Wrote very long log entry for first time at 12:30 am Saturday.

Friday, June 15, 2001
This is the first time I have posted to our weblog. We can't pick a colour for the web page background!

We got the key for a storage in the 499A lab.

Thursday, June 14, 2001
Saw Mary Anne Teo today to allow us all access to the old ELEC 320 lab. Now we have a place to setup all of our equipment for testing and a bit of design.

Wednesday, June 13, 2001
Emailed Marcie and Darrin to see if this weblog will be used or not.

Alouishus was contacted today, and Darrin arranged for it that he did the simple coding for the LabView pseudo driver for the DAQ. He will make it customizable, so we can test it with different types of sample inputs. We should have a version from him by next Friday. Then we can test the system quickly with a simple sine wave, if we have a working link setup with all the debug boards.

This is the first test post.