FPGA development station in the works

The Spartan 6 development board powered up OK.
A fresh install of Windows on the development machine has been completed.
The development environment (ISE Webpack 12.3) has been installed.

Next up: update the ISE to 12.4 and figure out how to share the station. 
 -Michelle W5NYV

Spartan-6 hardware purchased, ISE 12.4 released from Xilinx, and filter solution provided by Bob

I bought us a development kit in order to provide some hardware to work on (you all might recall that the loaner DSP-centric development kit didn't work out for us). 

The goal is to put it on the net so that any of us can access it and do development. The way to accomplish this is probably through a VPN and/or screen sharing setup. I'll have a computer dedicated to the station that will (hopefully) stay up and be accessible all the time!

Here's a link to the kit:

http://www.xilinx.com/products/devkits/EK-S6-SP601-G.htm

And, 12.4 ISE (we use the free webpack version) has just been released. This is the software that allows you to develop on Xilinx FPGAs. Here's the download link:

http://www.xilinx.com/support/download/index.htm

Please update your ISE and stay tuned for more FPGA updates   :+)

Also, Bob McGwier has provided a filter solution (which I'm sorry to say I haven't had a chance yet to do much with quite yet). Thank you Bob!

-Michelle W5NYV

Greetings everyone!

I have a question. I'm confused on page 176 in the Six-Port Technique book. I'm working on an Octave model of six-port modulation and demodulation. It takes four reflection states, modulates, then demodulates. I am expecting to be able to show how a six-port device works with this model.

Determining the demodulation coefficients is an important step. There's three matrices. A, B, and X. A is composed of power out for all ports and all reflection states. B is the constellation points defined. X is the demodulation coefficients. 

The book says to do a least squares solution for X that minimizes the norm of B=A*X. 

The problem I'm having is understanding what the right sizes for the matrices are. 

For QPSK, it would seem to me that B and X are both 8x1. However, the size for A isn't 8x8, which is (I think) what it would have to be in order to multiply A times X. 

In my case, the number of constellation points M (for QPSK) is 4. This means that X has to have 8 values. There are four sets of two values that determine the constellation points.

I'm implementing a six-port model, so the number of ports N is 4. The notation seems to indicate that the matrix A is 4x8, but multiplying a 4x8 times a 8x1 results in a 4x1 matrix, and not a 8x1 matrix.

Either I have the size of B wrong, or I have the size of A wrong. I'm pretty sure I have the size of X right.

I think the size of B for QPSK should be 8x1 because of how it's used on page 166. Each of the Powers (from 4 ports) is multiplied by a particular demodulation coefficient. If I have 4 "I" and 4 "Q", then that should be eight demodulation coefficients in all, for an 8x1 matrix.

So, given all that, I'm thinking that I'm not understanding the notation for the matrix A, or else not understanding what the vertical and horizontal bars mean within A, B, and X.

Please let me know where I'm botching this - I'm getting a constellation out at the end using an abridged X of four elements (in order to match the size and sort of limp in with a fake BPSK), but it's severely distorted, and I think getting the correct A would make the ideal-case model to behave correctly and result in a milestone being met.

I attached the model as a text file.  I know it's difficult to interpret other people's code, but here is the current version for reference.

I also attached the most recent demodulation result so you can see that the output isn't quite there yet - but it's close. I'm not sure why the title keeps getting cut off - there is possibly something I need to do to make gnuplot give me more margin so this doesn't happen, but I've been concentrating on getting the model corrected and have put off polishing the graphics for later.

Working on this is very exciting, and we've been able to make progress. I'm looking forward to making some hardware, and have found some practical references for combiners and couplers. I am still working on finding use of HFSS, but did track down someone with an older copy of the program who is supposed to bring it to me at one of the next microwave meetings, and I think Roger AD5T had a lead on a copy too. 

Using a local company's version didn't work out due to the license agreement that the company had with the vendor of HFSS.

More soon,

-Michelle W5NYV

six-port document updated

http://www.delmarnorth.com/microwave/newsletters/sixportmodel.pdf  has been updated with feedback received today. Thank you! 

early six-port feedback and call for more

A hearty thanks go out for the early feedback on the six-port document! I've got some good ideas for improvements and am looking for more. If you have not gotten a chance to read http://www.delmarnorth.com/microwave/newsletters/sixportmodel.pdf then please do. I need help with making this document work, and am genuinely interested in making it better. 

There is indeed a calibration issue with six-ports. I read an academic paper that described what is the equivalent of a two-tone test for six-port calibration. This paper describes a procedure for calibrating six-port devices without having to have an IPO's worth of test equipment, and instead using (essentially) an over-the-air or continual calibration. 

I know these things (six ports) may seem like RF black magic and all, but my aim is to plow through the basics of the devices and see what works for amateur radio. On the face of it, we get large bandwidth and good performance from passive devices and simple layouts, with direct conversion from microwave to I and Q. Where we "pay" for this performance is in terms of calibrating the device, and in the signal processing requirements of the FPGA that receives this (jumbled mess?) of I and Q. I believe we're up to the task, though. 

This document's scope is the ideal case, or the model of the six-port structure. The real six-port device is going to have different parameters and settings and calibrations, because things like non-ideal quadrature hybrid couplers and non-ideal 3dB dividers are reality, and we build reality, not models. However, the model will help define what we're after, and I'm still working out what the ideal case is. 

Any feedback you have on the document is appreciated, and please feel free to share it with the list. 

 

More soon!

-Michelle W5NYV

Draft document for review - six port device model in Octave

Greetings! 

Here's a draft of the documentation for (and the Octave code listing of) the six-port modem for MEP. It's an early draft, but the demodulator finally made a bit of sense, and I'd like to share that progress as well as ask for a review. Please give me your feedback on this attempt at making sense of six-ports.

http://www.delmarnorth.com/microwave/newsletters/sixportmodel.pdf

Improvements in progress are a better graphic of the six port structure, with color lines indicating the various waveforms as they gozinta and gozouta. An animation would really do the trick, I think.

More soon!

-Michelle W5NYV

Potestatem obscuri lateris nescis.

progress with octave model

Greetings MEP!

Due to a block of uninterrupted time, I managed to hack and slash my way through beginnersville in Octave. I conquered plotting today. Right now, I have an RF and an LO signal attractively plotted in a png (attached). 

The goal is to model the five-port device in Octave, then build it in VHDL. If  you have MATLAB, you should be able to load up the Octave model (attached as well)

If you are wondering what a five-port device is, please know you are not alone. If you have access to IEEE Communications June 2010 issue, then there is an article in there that describes them, including some built and tested examples. 

Here's a snippet from an optical article in wikipedia that refers to the superset of the five-port, which is named six-port. In the IEEE article, the sixth port is described by a dependent equation if you assume that you know the local oscillator power. Since the designer should know this, the design can be simplified down to a five port device. Five ports is as simple as you can get, and has almost all the performance of a six port device. 

"In principle, the six-port device consists of linear dividers and combiners
interconnected in such a way that four different vectorial additions of a
reference signal (LO) and the signal to be detected are obtained. The levels of
the four output signals are detected by balanced receivers. By applying suitable
base-band signal processing algorithms, the amplitude and phase of the unknown
signal can be determined."

I asked the author of the article for the design files used, and hope to hear a response. Having gerbers of a working five-port device that just happens to work on our bands would be a big step forward for this line of research. 

If you've worked on, with, or near six/five port devices, I'd love to hear about it. 

More soon!

 -Michelle W5NYV

Weekly Report 6 August 2010

Greetings MEPsters!

I have a report.

While pedaling away at the gym in continuing efforts to not be fat, I admitted to feeling kind of down in the dumps about tools for MEP. I was feeling somewhat chumpish because it isn't reasonable to ask participants to spend thousands of dollars on MATLAB, Simulink, etc. And, it's easy to start blaming the lack of tools for lack of progress. 

After given a pep talk concerning open source, I installed Octave (open source alternative to MATLAB) and found something called ScicosLabGtk (open source alternative to Simulink). I installed it too. 

After a couple hours of reading tutorials, Octave is less scary and more useful than I expected.

The practice problem I selected was to implement the constraint length 7, rate 1/2 code used on the Voyager space program. 

Also, some time back Roger AD5T sent an article from the June IEEE Communications journal about 5 port devices. I'm asking around to see if we can build some of these. The center frequency is 4.5GHz, and the bandwidth is a whopping 3GHz. The RF and LO are the inputs, and the various combinations thereof comprise 3 outputs. Power detectors are used to make an output signal. There are no mixers. It's kind of whacky, but the article showed working hardware that I'd like to duplicate and evaluate. That sort of bandwidth, by my reckoning, includes both MEP bands at 3.4 and 5.8GHz. 

I can't attach the article due to copyright issues, but I am working on getting it reinterpreted to share on mep-dev. More soon!

Here's an early snapshot of the Octave practice problem included below. It's not (yet) elegant. 

I'm going to do this problem in Octave, then implement it in VHDL using the free version of the Xilinx tools. Remember, version 12 is out, so install and/or upgrade. That will be our baseline VHDL tool for MEP. The idea is to have a mathematical model of the things we do in Octave, and a model in VHDL. The two implementations should agree. 

# Voyager Encoder

# we have a 7-bit register with taps on top

# at 0, 2, 3, 5, 6 (inverter)

# and taps on the bottom 

# at 0, 1, 2, 3, 6 (noninverted)

# signals are multiplexed at the end to get the result.

taps_inverted_side    = [1, 0, 1, 1, 0, 1, 1]

taps_noninverted_side = [1, 1, 1, 1, 0, 0, 1]

register = zeros(1,7)

register(1,1) = 1

# To access the item at row i and column j, just use the command  register(i, j)

# set up a loop

# !!!this needs to be made to work for arbitrary length input

i = [1:10]

for Clock_cycle = i

Clock_cycle

# !!!make this generic in the future. Gate the xors with the taps from above by using AND.

inverted_side = !xor(register(1,7),(xor(register(1,6),(xor(register(1,4),(xor(register(1,1),register(1,3))))))))

noninverted_side = xor(register(1,7),(xor(register(1,4),(xor(register(1,3),(xor(register(1,1),register(1,2))))))))

#print what is in our register

register

#advance values of register

register(1,7) = register(1,6)

register(1,6) = register(1,5)

register(1,5) = register(1,4)

register(1,4) = register(1,3)

register(1,3) = register(1,2)

register(1,2) = register(1,1)

register(1,1) = 0

endfor

Update from Defcon 18

Greetings from Las Vegas.

If you'd like to listen to the audio from a few talks that I've attended at DEFCON, then here are the links.

Moonbounce, by Matt Krick K3MK (closest thing to MEP so far)

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=xBdg9gnWT2z4

A request to hackers to collaborate with the Department of Defense.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=Pz91nFJvpvfH

A call to action from Dark Tangent concerning https: becoming the default experience for browsing the web.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=f1Tp9Cc0lXhd

Bytes and Bullets, an authors' panel. Authors have written books about cyberwarfare and share their perspectives on the issue.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=hqxcrT5RfDqG

I missed a talk about hacking FPGA bitstreams, but I'll try and track down the presenter tomorrow.

-Michelle W5NYV

FPGA for space applications

http://www.xilinx.com/products/virtex5qv/index.htm I've been keeping a lookout for components potentially useful for a digital satellite payload. What do you all think of this one?

NEON test code explorations

Hello everyone! Here's a bit of what's going on this week. 

We were looking again at dotproduct.c from the neon_test archive. This time, we were referring to it as a template for creating a version of dotproduct that takes 16-bit signed integer inputs and returns a 32-bit signed integer output. This is in order to port a demodulator Phil Karn is working on to ARM/NEON. This forced us to think more carefully aboutregister allocation, and we ran into a subtlety we didn't fully understand.

In the original dotproduct.c, half of the elements are multiply-accumulated into q8, and half into q9. Then at the end, q9 is added into q8. Like this:

...

vld1.32 {d0,d1,d2,d3}, [%1]!
vld1.32 {d4,d5,d6,d7}, [%2]!
vmla.f32 q8, q0, q2
vmla.f32 q9, q1, q3
bgt 1b
vadd.f32 q8, q8, q9
...

We thought, why not change this to accumulate directly into q8? This would be logically equivalent:

...

vld1.32 {d0,d1,d2,d3}, [%1]!
vld1.32 {d4,d5,d6,d7}, [%2]!
vmla.f32 q8, q0, q2
vmla.f32 q8, q1, q3
bgt 1b
# no vadd.f32 required
...

We ran this on the Beagleboard, and it does indeed get the same answer. But it's about 30% slower.

The two vmla instructions in the original code are independent in both inputs and outputs, whereas the two vmla instructions in our new version share the destination register q8. It would appear that the execution hardware in the processor on the Beagleboard is smart enough to do those two operations largely in parallel if the inputs and outputs are independent. That's very cool.

So, the questions are:

1. Is that the correct explanation of what's happening?

2. How were we supposed to know that such parallel execution was possible? Put another way, how can we find out whether the same is true of any other two operations, short of coding up multiple versions and trying them out?

3. There must be a limit on how many operations (such as vmla's) can proceed in parallel. I think there are enough registers available to do more in the dotproduct.c code, but the original code stopped at two. So I'm guessing the author was able to know that two was the maximum for parallel execution. Is this in the documentation somewhere or did the author have to run experiments?

Apologies to Philip Balister, who will get a slightly longer version of this email! 

We're making progress learning ARM and NEON code and enjoying ourselves in the process. 

-Michelle W5NYV, Paul KB5MU

Bit Error Rate Tester notes from today's strategy session

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=0kgpTq2CwW6x
-Michelle W5NYV

VHDL bit error rate tester update

A VHDL module was written today that implements a pseudrandom number generator (PRNG) with an external clock. This is another small step towards a bit error rate tester (BERT). KB5MU talked today about what a BERT looks like, and I learned that they come in pairs - there is a transmit side part of the tester, and a more complex receive side of the tester. It all made sense, and I will post a drawing of where we're going with the VHDL later tonight.

I made a quick summary of the website statistics for May, and am reading the documentation at Open Cores to see how to start a project.
 -Michelle W5NYV

PRNG seems to work

In the absence of thoroughly testing it, I can't state definitively that it is a wholly successful implementation, but the MEP "yet another pseudorandom number generator" VHDL module appears to work. Source code included below.
 
-Michelle W5NYV
 
 
----------------------------------------------------------------------------------
-- Company: Optimized Tomfoolery
-- Engineer: Michelle Thompson
--
-- Create Date:    16:34:20 05/28/2010
-- Design Name: BERT
-- Module Name:    PRNG - Behavioral
-- Project Name: MEP
-- Target Devices:
-- Tool versions:
-- Description: Pseudorandom Number Generator for Bit Error Rate Tester
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
 
entity PRNG is
    Port ( prn_out : out  BIT_VECTOR (7 downto 0);
           initial_value : in  BIT_VECTOR (7 downto 0));

 --declare signals here
 --clock
  signal Tic_Toc : STD_LOGIC := '0';
 --set signals
  signal Set0 : STD_LOGIC := '0';
  signal Set1 : STD_LOGIC := '0';
  signal Set2 : STD_LOGIC := '0';
  signal Set3 : STD_LOGIC := '0';
  signal Set4 : STD_LOGIC := '0';
  signal Set5 : STD_LOGIC := '0';
  signal Set6 : STD_LOGIC := '0';
  signal Set7 : STD_LOGIC := '1';  
 --reset signals
  signal Reset0 : STD_LOGIC := '0';
  signal Reset1 : STD_LOGIC := '0';
  signal Reset2 : STD_LOGIC := '0';
  signal Reset3 : STD_LOGIC := '0';
  signal Reset4 : STD_LOGIC := '0';
  signal Reset5 : STD_LOGIC := '0';
  signal Reset6 : STD_LOGIC := '0';
  signal Reset7 : STD_LOGIC := '0';  
 --results signals
  signal R7 : BIT := '0';
  signal R6 : BIT := '0';
  signal R5 : BIT := '0';
  signal R4 : BIT := '0';
  signal R3 : BIT := '0';
  signal R2 : BIT := '0';
  signal R1 : BIT := '0';
  signal R0 : BIT := '0';
 --feedback signals
  signal F3 : BIT := '0';
  signal F2 : BIT := '0';
  signal F1 : BIT := '0';
  signal F0 : BIT := '0';
    
end PRNG;
 
architecture Behavioral of PRNG is
--clock source
 component clock
  generic (PULSE_WIDTH : TIME);
  port (clock: out STD_LOGIC);
 end component;
 
 
--d flip flop component
 component d_flip_flop
  port (data_in: in BIT;
    clock: in STD_LOGIC;
    data_out: out BIT;
    set: in STD_LOGIC;
    reset: in STD_LOGIC);
 end component;

--xor gate component
 component exor
  port ( xor_data_in_a : in  BIT;
     xor_data_in_b : in  BIT;
     xor_data_out  : out  BIT);
 end component;

begin
 Set7 <= '0' after 10 ns;

 Synch: clock
  generic map (PULSE_WIDTH => 5 ns)
  port map (Tic_Toc);
  
 Do_xor_01: exor
  port map (F0, R2, F1);
  
 Do_xor_02: exor
  port map (F1, R3, F2);
  
 Do_xor_03: exor
  port map (F2, R7, F3);
 
 Drive_Flip_Flop_0: d_flip_flop
  port map (R1, Tic_Toc, R0, Set0, Reset0);
  
 Drive_Flip_Flop_1: d_flip_flop
  port map (R2, Tic_Toc, R1, Set1, Reset1);
  
 Drive_Flip_Flop_2: d_flip_flop
  port map (R3, Tic_Toc, R2, Set2, Reset2);
 Drive_Flip_Flop_3: d_flip_flop
  port map (R4, Tic_Toc, R3, Set3, Reset3);
 Drive_Flip_Flop_4: d_flip_flop
  port map (R5, Tic_Toc, R4, Set4, Reset4);
 Drive_Flip_Flop_5: d_flip_flop
  port map (R6, Tic_Toc, R5, Set5, Reset5);
 Drive_Flip_Flop_6: d_flip_flop
  port map (R7, Tic_Toc, R6, Set6, Reset6);
 Drive_Flip_Flop_7: d_flip_flop
  port map (F3, Tic_Toc, R7, Set7, Reset7);
end Behavioral;

D flip flop tested, seems to work, next steps

I wrote another two VHDL modules in the effort to test the D flip flop code. I wrote an inverter in order to have an external inverter component and get some practice with incorporating components into architectures. I also wrote an architecture module. An architecture is a collection of components linked by signals. The architecture code is at the bottom of this email. Essentially, an architecture is a circuit. The components can be thought of as devices or ICs.

So, it seems to work. The flip flop is hooked up in a way that the inverted output is fed back in to its own input. This creates a divide by two counter, and that is indeed what happens in the simulator.

What are the flip flops for? They are the building blocks of the bit error rate tester, which will be implemented in an FPGA and will be used to measure the performance of the receiver.

While this isn't bad for a beginner, and while the layout of a bit error rate tester is straightforward, the strategy for the actual receiver is not as clear-cut. I have a growing competence with what a Costas Loop does, and it's starting to make some sense, but the identification of individual modules is going to probably proceed pretty much like this effort, with the individual components being built up from very simple starting points.

Next steps:
1) Work on the website to better archive/present/share/explain the VHDL
2) Put the flip flops together to make a pseudorandom number generator and test it.

Here's the code:
----------------------------------------------------------------------------------
-- Company: Optimized Tomfoolery 
-- Engineer: Michelle Thompson
--
-- Create Date:    10:53:22 05/28/2010
-- Design Name: BERT
-- Module Name:    test_flip_flop - Behavioral
-- Project Name: MEP
-- Target Devices:
-- Tool versions:
-- Description: hook up flip flop and clock and see if it works
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity test_flip_flop is
 --declare signals here
 signal Tic_Toc : STD_LOGIC := '0';
 signal Output_Data : BIT := '0';
 signal Output_Data_Inverted : BIT := '0';
 signal Set : STD_LOGIC := '0';
 signal Reset : STD_LOGIC := '0';
end test_flip_flop;

architecture Behavioral of test_flip_flop is
 component clock
  generic (PULSE_WIDTH : TIME);
  port (clock: out STD_LOGIC);
 end component;
 
 component d_flip_flop
  port (data_in: in BIT;
    clock: in STD_LOGIC;
    data_out: out BIT;
    set: in STD_LOGIC;
    reset: in STD_LOGIC);
 end component;
 
 component inverter
  port (inverter_data_in: in BIT;
    inverter_data_out: out BIT);
 end component;
 

begin
 Synch: clock
  generic map (PULSE_WIDTH => 50 ns)
  port map (Tic_Toc);
  
 Invert: inverter
  port map (Output_Data, Output_Data_Inverted);
 
 Drive_Flip_Flop: d_flip_flop
  port map (Output_Data_Inverted, Tic_Toc, Output_Data, Set, Reset);
end Behavioral;
----------------------------------------------------------------------------------

and now... a clock!

In order to drive the flip flop, a clock was coded up in VHDL. Here's the code below.

The clock period is set with a local variable called PULSE_WIDTH.

Again, very simple and basic, but making progress.

We've been studying a book by U. Meyer-Baese called "Digital Signal Processing with Field Programmable Gate Arrays". There's a section on Costas Loops that reiterates what Bob McGwier said about phase and gain sensitivity. So, we're on the right track!

We'll most likely start storing these files on the website. Another place they will live, as a project, will be at the Open Cores website, where lots of open source HDL projects are hosted.

----------------------------------------------------------------------------------
-- Company: Optimized Tomfoolery
-- Engineer: Michelle Thompson
--
-- Create Date:    09:40:09 05/27/2010
-- Design Name: BERT
-- Module Name:    clock - Behavioral
-- Project Name: MEP
-- Target Devices:
-- Tool versions:
-- Description: Clock that drives d flip flop
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity clock is
 generic (PULSE_WIDTH : TIME := 20ns);
    Port ( clock : out  STD_LOGIC);
end clock;
architecture Behavioral of clock is
begin
 Gen_Clock:
 process
  constant PERIOD: TIME := 2*PULSE_WIDTH;
 begin
  clock <= '1' after PULSE_WIDTH,
     '0' after PERIOD;
  wait for PERIOD;
 end process Gen_Clock;
end Behavioral;
----------------------------------------------------------------------------------

more soon, 
-Michelle W5NYV
Potestatem obscuri lateris nescis.

d flip flop synthesized

After some reading and some learning, I was able to synthesize a D flip flop in VHDL using Xilinx ISE (webpack version 11).

It's a small step, but it's a building block for a pseudorandom number generator that will be used in the bit error rate tester. This tester (BERT for short) will be used as a tool to test the MEP receiver.

It's such a short bit of code so far that I'm going to include it in this email in its entirety!   :+)    
 
Here it is:

----------------------------------------------------------------------------------
-- Company: Optimized Tomfoolery
-- Engineer: Michelle Thompson
--
-- Create Date:    08:32:51 05/26/2010
-- Design Name: Bit Error Rate Tester
-- Module Name:    d_flip_flop - Behavioral
-- Project Name: MEP
-- Target Devices:
-- Tool versions:
-- Description: A bit error rate tester for MEP receiver
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity d_flip_flop is
    Port ( data_in : in  STD_LOGIC;
           clock : in  STD_LOGIC;
           data_out : out  STD_LOGIC;
           set : in  STD_LOGIC;
           reset : in  STD_LOGIC);
end d_flip_flop;

architecture Behavioral of d_flip_flop is
begin
 process (data_in, clock, set, reset)
 begin
 -- asynchronous reset output to 0
 if (reset = '1')
 then data_out <= '0';
  -- asynchronous set output to 1
  elsif (set = '1')
  then data_out <= '1';
  
  --clock rising edge
   elsif(clock='1' and clock'event)
   then data_out <= data_in;
 end if;
 end process;
end Behavioral;
----------------------------------------------------------------------------------

Next step is to document in a way that makes it easier to participate. Then, add code that makes the inputs wiggle so that the outputs wiggle. Then, test to make sure it behaves exactly as a D flip flop should. This will be the first component in the MEP VHDL library of parts that will make up the tools and pieces of the system.

More soon!
-Michelle W5NYV

Potestatem obscuri lateris nescis.

Update to MEP costas loop RX, FPGA virtual conference

Latest sketch attached!

End of school year here at my household, so have been a busy bee for the past few weeks.

There is a "virtual conference" coming up for FPGAs. Check out http://www.eetimes.com/FPGA/ for more details.
-Michelle W5NYV

MEP_Rx1.3 Added Bob's Comments about adders

Here's this morning's additions to the doodles.

FPGA 1.2 drawing and questions

Here's our notes from this evening's conversations about the MEP receiver, using an FPGA.
-Michelle W5NYV

----- Original Message ----
From: Paul Williamson <paul.kb5mu@gmail.com>
To: Bob McGwier <rwmcgwier@gmail.com>
Cc: "mep-dev@uppermeadow.com" <mep-dev@uppermeadow.com>
Sent: Thu, April 15, 2010 9:15:07 PM
Subject: Re: [Mep-dev] FPGA 1.1 drawing and questions

This sounds really useful! Can you provide more details, or a reference to a paper, or the source code for an implementation, or something we can refer to?

73. -Paul KB5MU

On Apr 2, 2010, at 7:16 AM, Bob McGwier <rwmcgwier@gmail.com> wrote:

> In the FPGA prior to the costa's loop you will need a nonlinear
> equalizer and DC elimination. The QSD, done in this case with some
> fairly high speed switches and baseband filtering most likely, will
> have both amplitude and phase imbalance in the I/Q legs and further, it
> is frequency (rate of switching the sampling "capacitors") dependent.
>
> I have devised an algorithm which really makes the difference in the
> performance of these devices (out of necessity). Especially for digital
> signals, this is imperative.
>
> Suppose Z is the incoming signal AFTER the QSD. Z* (complex conjugate)
> is taken, and a filter is applied to Z*, and the applied to a delayed
> copy of Z. This sufficiently eliminates the image rejection imbalance
> to make it an unimportant part of the communications system.
>
> An ASSUMPTION of the algorithm is that there is NO DC component, so it
> must be eliminated before F(Z*)(n) is applied to Z(-n) and the
> reestimation of F is done.
_______________________________________________
Mep-dev mailing list
Mep-dev@uppermeadow.com
http://uppermeadow.com/mailman/listinfo/mep-dev

Add NEON support to FFTW - draft

We started working through the existing code in the simd directory of fftw, and here is what we learned about simd-sse.h. Our comments are in black serif text. We got about halfway through before other chores interrupted.

http://www.delmarnorth.com/microwave/software/simd-sse.h.discussion.draft.pdf

The plan here is to understand what the current set of simd code is doing, and then write code for neon to present for review. Several simd processors are already supported by FFTW, so learning how they work will help in creating code for NEON.

If you would like to participate, grab the latest version of FFTW source code (we're working with 3.2.2), go to the simd directory, and walk through the code. If you are already a black belt in FFTW simd code, then by all means speak up - we'd love to accelerate the process! We'll keep working on simd-sse.h until we understand it, then will move on to another header file. When all the header files are understood, we'll write down what we think a neon header file must accomplish.

-Michelle W5NYV

Minor revision to Neon Test Tutorial - font change

If you didn't like the Papyrus, then I hope you'll like Helvetica.

I'm a fan of the movie, myself.

http://www.delmarnorth.com/microwave/requirements/neon-test-tutorial.pdf
-Michelle W5NYV

Potestatem obscuri lateris nescis.

Evaluation board ordered - Direct Quadrature Demodulator from Skyworks

Here is the data sheet for the evaluation board ordered for MEP and other local microwave groups that may want to experiment on 3GHz with direct digital downconversion. The frequency band selected was 3200-3900MHz.

Datasheet here:
http://www.skyworksinc.com/uploads/documents/200473B.pdf

I need a recommendation for an A/D converter to feed our I and Q signals to. The FPGA would pick things up from there.

-Michelle W5NYV

Potestatem obscuri lateris nescis.

Neon Test Tutorial - published version

Here is the published version of the NEON test code tutorial. Next step, add neon support to FFTW.

Statistics for March 2010

Thank you all for being interested in and supportive of MEP development.

Here are some statistics for March

Average daily number of RSS feed subscribers: 31
Number of subscribers on the mailing list: 37
Unique visitors in March: 744

6.54GB were downloaded from the site for December. This is well within our bandwidth allocation. We are well within our disk space quota as well. No service disruptions were reported for March.

The most popular items were the Xilinx manuals, the SBMS Newsletter from March 2010, The High-Speed Multimedia notes from February, and the Xilinx Integrated Software Environment.

Many visitors to the site were from the USA. However, Hong Kong was the most frequent visitor, and India and Australia ranked high as well.

Please let me know what would make the site, feed, and list more useful and helpful and I'll do all that I can to achieve it. Since so many of us are spread out so far, a useful site and tool set is important in order to communicate effectively.

Updated MEP Software Page

I added a description of how to obtain our FPGA software tool (free) from Xilinx.

http://www.delmarnorth.com/microwave/software.php

FPGA 1.1 drawing and questions

Here's today's sketch of the FPGA. It now has stuff coming out the other side!

One of the comments was to go ahead and connect the FGPA to a processor, like the TI OMAP in the Beagleboard, directly. I'm assuming that it's connected directly in a large parallel interface to memory. There's a lot of available pins on the TI OMAP.

Another FPGA output could be IPv6 and IPv4 packets.
-Michelle W5NYV

weekly plan 29 March - 2 Aril 2010 "Costas Loop in VHDL, IQ Demodulator Evaluation Boards"

Greetings everyone,

Here's my plan for the week.

1. (Begin to) implement a Costas Loop in VHDL. Anyone out there already done this?
2. Set up the website for sharing VHDL source code. I noticed several VHDL projects on sourceforge. Perhaps when we have some code to share, starting a sourceforge project area would be a good idea.
3. Fix the twitter badge belonging to one of the three people that have a twitter badge on the MEP homepage. If you use twitter, and would like to be on the home page, just let me know and I'll put you there.
4. Decide whether or not to order an evaluation board for an IQ demodulator. I'm looking at something like a Skyworks evaluation board. They come with the demodulator soldered down, but you place the other parts to get the right frequency range. There's a parts list for 3200-3900MHz, which just happens to include one of our intended bands.

Here's the rather unrevealing product webpage:

http://www.cdistore.com/skyworks/PortalProductDetail.aspx?ProdId=189271

My questions are "Are there any other cheaper alternatives to this evaluation board?" and "Does anyone have anything like this lying around that we could borrow?" Let us know. I might be able to get a lot of use out of this evaluation board in the local microwave scene as a loaner or building block, but $199 is expensive enough to justify talking about it and looking around some more.

If you have the time and inclination to help confirm or contradict any of these ideas, please do! It would be greatly appreciated.

More soon,
-Michelle W5NYV

MEP receiver proposal - with FPGA (very high level beginning sketch)

Here's the basic idea. More to come. Please let me know what you think.
-Michelle

Weekly Report 22-26 March 2010: FPGA updates and a ham radio modem design

Here is a weekly report for 22-26 March 2010.
 
-=-=-=-=-=-=-=-=-=-
 
I started reading a book about reconfigurable computing.
 
http://www.amazon.com/Reconfigurable-Computing-Practice-FPGA-Based-Computation/dp/0123705223/ref=sr_1_1?ie=UTF8&s=books&qid=1269626740&sr=8-1
 
This type of computing uses FPGAs in order to perform computations. The CPU chooses from a variety of configurations in order to set up an FPGA to solve a particular problem or set of problems. One has to figure out if the overhead of reconfiguring the FPGAs is worth the time saved by dedicated hardware (the designs in the FPGAs). It's made for some interesting reading, that's for sure. I got the book thinking it would be about general FPGA usage, but reconfigurable computing is somewhat of a specialized field that uses FPGAs as a tool to get the job done. "Real" reconfigurable computers have been designed and built and used successfully, but the market just isn't there for most companies that have tried to build reconfigurable computers as a commercial endeavor.
 
Now, there isn't that much here that affects MEP. Our computations are not (I don't think) difficult or wide-ranging enough to have to build a configuration management processor and swap out configurations. However, the chapter on learning VHDL is useful, and the compute vs. dataflow modeling explanations were illuminating and (to me) fun to read.

-=-=-=-=-=-=-=-=-=-
 
The free version of the older Integrated Software Environment (version 10.1 of the ISE) for Xilinx FPGA development did not support the larger Virtex II FPGA in the XtremeDSP Development kit. I downloaded the current free version of the ISE, and as expected, it didn't support families of FPGAs earlier than the Virtex IV.
I updated it from (free) version 11.1 to (free) version 11.5, which added the very latest Spartan 6 family to the ISE. While there isn't any target hardware doing it this way, it does allow us to develop for the latest versions of the Xilinx Spartan chip. I packed up the development station that we were loaned and will deliver it back this weekend with our thanks.
 
To participate in MEP FPGA design, then download the 11.1 Webpack ISE from Xilinx and update it. When you update it, there will be one DSP-related thing that you will not be able to include. Uncheck that box, and you will be able to update to 11.5 for free.
 
Here is a page of Xilinx ISE 11 tutorials.
 
http://www.xilinx.com/support/techsup/tutorials/tutorials11.htm
 
-=-=-=-=-=-=-=-=-=-
 
I decided to look around for other amateur radio FPGA projects and found some mention of FPGA in amateur radio in a TAPR newsletter and found a modem project by a ham, which was implemented using Xilinx FPGAs. Summary is below.
 
Ham Radio Systems On A Chip by Steve Bragg KA9MVA from TAPR Packet Status Register #102 located at http://www.tapr.org/psr/psr102.pdf
 
"...the latest field programmable gate arrays (FPGAs) pack enough digital hardware to be called SoCs in their own right. Falling prices, exponentially increasing gate counts, and low-cost design software are converging to make FPGAs the right technology for emerging ham radio systems-on-a-chip."
 
"A ham radio SoC includes signal processing 'blocks' for the most popular modes of ham radio: analog and digital voice, ATV/SSTV, packet, data and APRS®. Vocoders and decoders, such as that developed by G4GUO and G4JNT3 can be included. Audio processing (such as speech processing, VOX and stereo synthesis) can be in the SoC. Packet engines and TNCs should also be included.
 
An example of an FPGA-based TNC device is Nico Palermo, IV3NWV's YAM modem4, released in 1997. The TNC-like YAM was based on the Xilinx XC5200-series FPGA, the equivalent about 3,000 gates5. IV3NWV's clever coding crammed both 1200-bit/s AFSK and 9600-bit/s G3RUH modems into a small Xilinx FPGA. Today, the equivalent of the YAM, and much more besides, can be incorporated into a ham radio SoC."
 
The YAM (Yet Another Modem) Modem can be read about here:
 
http://sharon.esrac.ele.tue.nl/pub/packet/yam/
 
Three configuration files can be downloaded by email request. The "features" section discusses the details of the modem.
 
-=-=-=-=-=-=-=-=-=-

Update!

We walked through the short tutorial, which makes a simple counter and then provides a testbench waveform to wiggle bits, and found out something important.

The Xilinx ISE 10.1 free "webpack" doesn't target the FPGA in the XtremeDSP development kit. The free version tops out at the Virtex II version 400. Ours is a Virtex II version 3000.

Next step: Download the Xilinx ISE 11 free "webpack", and see if it has supported device limits. Version 11 doesn't' support the older Virtex II chip, but it can target the modern current FPGAs. I'll write more about what I find out in a bit.

-Michelle

Xilinx webinar notes, FPGA station

Here's the notes I took during the Xilinx "Achieving 1000 GMACs of DSP Performance with Xilinx FPGAs" webinar.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=fmnmFlw9JqXW

A GMAC is Giga Multiply-Accumulate Operations Per Second. This is somewhat similar to the measurement of "operations per second" for processors, and provides one way to compare and contrast circuitry that is capable of doing multiply-accumulates.

The thing that got my attention was what I sketched out on page 4, which is how many more MACs FPGAs are currently doing (with the Virtex and Spartan 6 series) when compared to "conventional" DSPs.

I'm reading a book on reconfigurable computing, which is an area of computing that has "settled" for using FPGAs. A "true" reconfigurable computer isn't exactly modeled or enabled by an FPGA, but since FPGAs are a commodity device, the field of reconfigurable computing seems to have coalesced around them. The book essentially echoes what the "sellinars" say. FPGAs are a "for real" DSP device.

What I got from this is that using FPGAs for MEP is not misguided. :+)

Anyone coming along with another development station? I've read through the short tutorial for using Xilinx ISE 10.1 and might actually be able to show off a "hello world" application sometime today.

-Michelle W5NYV

Potestatem obscuri lateris nescis.

Xilinx ISE 10.1 Design Suite Software

Xilinx (Integrated Software Environment) ISE 10.1 Design Suite Software, which allows you to take the VHDL code and turn it into a bit file, which is then loaded into an FPGA to program it for a particular set of tasks... is being downloaded as I type. Exciting stuff!

You can get the ISE 10.1 software free from the Xilinx web site. The current version is 11, but a link in the upper right hand of the Downloads Entitlement Page reads "Looking to register 10.1 or earlier software products?"

If you click that, you can download ISE WebPACK 10.1 as a free download.

This, as best I can tell, supports the Virtex II. The current version of the ISE picks up at Virtex IV.

Here's a document from Xilinx that might be helpful in finding documentation about ISE 10.1.

http://www.xilinx.com/itp/xilinx10/books/manuals.pdf

Notice that you can do simulations with this software.

More soon,-Michelle W5NYV

San Diego Microwave Group meeting announcement

Hello San Diego Microwavers,

Monday evening, March 15th is the date for this month's meeting of the San Diego Microwave Group.

Location is Kerry Banke's home at 6026 Poppy Street in La Mesa and starting time is 7:00 PM.

Kerry (N6IZW) announced the technical topic will be on Phase Lock Loop (PLL) Local Oscillator circuits and performance.

Bring your latest show and tell gear, and any unidentified microwave objects. We will see if anyone can help you figure out what they do. The meeting will start in Kerry's garage workshop where the test equipment is available.

Hope to see you there!!
73s from Ed Munn, W6OYJ
858-453-4563
remunn@earthlink.net

HSMM Webinar Notes 6 Feb 2010

Here's a link to my livescribe notes from the HSMM webinar held 6 Feb 2010.

http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=p11KKd4NvZFc
-Michelle W5NYV

Potestatem obscuri lateris nescis.

San Bernardino Microwave Society meeting tonight in Corona, CA

A couple of us will be at the San Bernardino Microwave Society meeting tonight at 7:00pm in Corona, CA. Please come and check out the meeting if you're able - tonight's presentation is described below:

"At the 4 March 2010 SBMS meeting the "Tech Talk" will be Tony, KC6QHP talking about a wide range of
activities to support the construction of a 47 GHz radio. Including; EDM machining, making waveguide switches,
embedded microcontroller for TR switching, building a suitable tripod head, acquisition of hard to get parts (caps,
wire bonding wire, substrates, chips, epoxies, etc.) putting together circuits with MMICs, interfacing to and from
bare die MMICs, etc. The SBMS meets at the American Legion Hall 1024 Main Street (south of the 91 freeway) in
Corona, CA at 1900 hours local time on the first Thursday of each month. Check out the SBMS web site at
http://www.ham-radio.com/sbms/."

Link to this month's SBMS Newsletter here:

http://www.ham-radio.com/sbms/newsletters/2010nwsltrs/03sbms2010.pdf

-Michelle W5NYV

Potestatem obscuri lateris nescis.

#ekiga irc channel chat log

Here's a bit of conversation about Ekiga on Beagleboard that happened today.

(10:59:26 AM) Michelle: Hello!
(10:59:50 AM) Michelle: Anyone have Ekiga working on a Beagleboard?
(11:02:41 AM) johanbr [~j@JBrannlund2.MathStat.Dal.Ca] entered the room.
(11:17:44 AM) Snark: Abraxas3d, someone proposed patches recently for arm support, if I remember well
(11:19:33 AM) Snark: https://bugzilla.gnome.org/show_bug.cgi?id=611308
(11:19:46 AM) Snark: ^^^ that was that bug
(11:22:29 AM) Michelle: That looks promising - I'm still in the process of figuring out what is most likely causing Ekiga to crash. Is there any way I can help with getting Ekiga working on ARM?
(11:24:32 AM) Michelle: Do I take these attachments and add them to my source for ptlib and ekiga, to try them out?
(11:25:19 AM) Michelle: they look like scripts, to me.
(11:25:51 AM) Snark: they are patches
(11:26:03 AM) Snark: notice that they only add support for video
(11:26:15 AM) Snark: which would imply the rest is already working properly
(11:26:45 AM) ced117 [~ced117@AStrasbourg-157-1-11-114.w90-40.abo.wanadoo.fr] entered the room.
(11:35:17 AM) Michelle: Segmentation faults are all I seem to be getting so far. The beagleboard "ideas" website described Ekiga as "already compiled for the arm-7 on Angstrom (Angstrom being the OS). So The project would be to optimize it for the Beagle (and probably some debugging as Ekiga on beagle apparently is not that stable)." When I read this entry on the table of Beagleboard Ideas (from 2009), I took it to mean that a large part of or almost all of the work was probably done. The stability problems appear on beagleboard various forums - people that were able to get it running experience crashes and other setbacks.
(11:36:10 AM) Michelle: I'm optimistic it's well within striking range, if not already solved. I've just not had a lot of luck finding the magic recipe or thing I'm missing.
(11:36:19 AM) Michelle: the link to the bug report is very helpful!
(11:36:42 AM) Michelle: at the very least, encouraging.
(11:43:38 AM) Snark: if you can get traces, that would help find bugs
(11:44:10 AM) Snark: http://wiki.ekiga.org/index.php/Debugging_Ekiga
(11:44:16 AM) Snark: ^ explanations how to debug
(11:45:39 AM) Michelle: I do indeed have some traces, and have that link marked for reference. I don't want to waste anyone's time with traces that are due to trivial problems on my end, so I haven't submitted any quite yet.
(11:50:34 AM) Snark: ok
(11:50:48 AM) Snark: does the fact that parts of ekiga come as plugins help?
(11:53:13 AM) [L] [~iruan@dyn128-54-240-70.ucsd.edu] entered the room.
(11:53:35 AM) Michelle: I confess I don't know enough about plugins (other than the basic programming theory) in Ekiga to know if it helps or hurts. When installing, there is a directory of plugins, and they are populated. If there is a missing plugin, I would probably not be able to tell without being better oriented to using and installing plugins.
(11:54:45 AM) Michelle: I'll do my best to check, though.
(11:54:57 AM) Snark: which plugins are enabled?
(11:55:07 AM) Snark: they should all be optional things
(11:55:18 AM) Snark: so removing them to remove their problems could be an idea
(11:59:47 AM) Michelle: none currently installed in the release considered stable from Angstrom (3.2.0), and I'm still working through the rebuild-from-source for 3.2.6. I do remember seeing plugins on the last attempt, and will try your idea when it rebuilds. I appreciate the advice very much.
(12:02:11 PM) Snark: 3.2.0 had some crashes here and there, which have been fixed since

Ekiga crashing on Beagleboard

I have revision B7 Beagleboards (TI OMAP processor, which has an ARM Cortex A8 CPU).

I'm running Angstrom, and Ekiga was obtained from the software repository. I'm very interested in using Ekiga for an amateur radio project.

Ekiga crashes, though, and I'm trying to figure out why. I'm hoping one of you out there has already traveled this path, and might be able to point out where I'm going wrong.

I ran dbg following the instructions at http://wiki.ekiga.org/index.php/Debugging_Ekiga, and got the following.

Program received signal SIGSEGV, Segmentation fault.
0x4000ac6c in ?? () from /lib/ld-linux.so.3

The full file created by gdb is here:
http://microwaveengineeringproject.blogspot.com/2010/02/gdb-results-for-ekiga-on-beagleboard.html

I know that ld-linux.so.* libraries find and load the shared libraries needed by a program, get the program ready to run, and then run it. I saw that Ekiga needed ptlib and libopal. These libraries are installed, along with their -dbg versions for gdb, and -dev version

I'm confident Ekiga should work on the Beagleboard because I found this photograph by Koen on Flickr.

http://www.flickr.com/photos/koenkooi/3208840095/

gdb Results for Ekiga on Beagleboard

michelle@beagleboard:~$ more gdb-ekiga.txt
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-angstrom-linux-gnueabi"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/bin/ekiga -d 4
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x4000ac6c in ?? () from /lib/ld-linux.so.3
(gdb) thread apply all bt
(gdb) quit
The program is running. Exit anyway? (y or n)
michelle@beagleboard:~$

Six-Port Device Notes

HSMM report 6 Feb 2010

Greetings MEPsters,

Today I was able to configure two WRT54GLs running OpenWRT. One was an access point with a wired connection to the internet, and the other was configured as a bridge. Beagleboards were attached to both of the WRT54GLs, and I could ping from both of them.

Here is a whiteboard block diagram of how these routers are configured.

http://www.flickr.com/photos/w5nyv/4332411901/

If that's too small (sorry about the white balance) then try this larger image.

http://www.flickr.com/photos/w5nyv/4332411901/sizes/l/

Today, I watched a webinar about High-Speed Multimedia Webinar. I noticed the webinar at the last minute - otherwise I would have mentioned it earlier.

Here's the writeup about it.

-=-=-=-=-=-=-=-

HSMM-MESH(tm) Networking Seminar

The HSMM-MESH(tm) Networking Seminar will cover all aspects of the HSMM-MESH
software developed in Austin, TX. The Webinar will begin with an explanation of
High-Speed Multi-Media (HSMM) and the subset of this topic which uses modified
Linksys WRT54GL 2.4 GHz Wireless Routers to form a mesh network, handy for high
speed digital communications in the ham band - for emergencies, special events
and field day.

The Webinar will cover applications, antennas, hardware, and the software. You
will learn how to load the software and how to configure it.

In the second part there will be a lab where we will actually load the software
into a router and configure the router. You will need a Linksys WRT54GL (any
version) or a WRT54G (Version 1.1 through 4 - version 5 or higher
will NOT work.)

The Webinar will be online at 8:00am Central time to give you a chance to get
logged in and test your setup before something starts happening. Training
starts at 9:00am with 10 minute breaks about every hour. And we will finish
in the afternoon after a lunch break.

You should Register before Saturday morning if possible. . If you have a
microphone and headset you will be able to ask questions verbally over VOIP.
Otherwise you can type in questions to be able to interact with the speaker.

The Webinar is provided through the courtesy of Ham-Com and is presented by
members of the NTMS-HSMM and Austin-HSMM groups. (contact...@kdream.com)
hsmm-mesh.org

-=-=-=-=-=-=-=-

There was a third part. Some of the third part was recorded by Jordan Cronin, and those recordings (he warned the quality might not be as good as he would like) can be found here:

http://qik.com/jordancronin

The seminar introduced HSMM and gave specific examples of its use in public service events. The configuration of their specific build of OpenWRT followed.

Read more about HSMM-MESH here:
http://www.hsmm-mesh.org/

For our application, I think there is a wrinkle with the HSMM-MESH software. On the hsmm-mesh site, I read the following passage.

"One feature of OLSR is called the "dynamic default gateway". When a node has internet access, as verified by periodic pings of various internet servers, it tells its neighbors that internet is available and the surrounding nodes will use this node as its default gateway. This is how every node gains internet access even if only one of them is connected to the internet. It still works if multiple nodes have direct internet access, but its behavior in this mode is not well tested. Sporadic internet access such as web browsing should handle this well. However, connections intended to be continuous, like streaming media, will definitely come to a halt if internet access switches from one node to another. This is because the IP address that you are accessing the internet from just changed and the far end will close the connection, as it should."

This sounds like that video streams would be interrupted? In our case, maybe we should investigate mobile IP? There is an RFC for mobile IP over IPv6, located here:

http://www.ietf.org/rfc/rfc3775.txt

I have this printed out and have plans to read it. There is another RFC for IPv4 as well. It's located here:

http://www.ietf.org/rfc/rfc3220.txt

The OLSR RFC can be found here:

http://www.ietf.org/rfc/rfc3626.txt

If you're lost in RFCs, then take heart - I am too!

What I'd like to do is get some sort of feeling as to what we'd have to add (if anything) to a build like OpenWRT in order to turn wireless routers into MEP prototypes.

The next step for the WRT54GLs here is to send video, with the source coming from USB webcams.


-Michelle W5NYV

Weekly Report 1 Feb 2010 - 5 Feb 2010

Hello everyone!

We're putting two Rev B beagleboards together with Linksys routers (WRT54GLs running OpenWRT) and experimenting with that combination for mobile MEPs. This is 2.4 GHz instead of our desired 3.4/5.8GHz full duplex plan, but will allow for easier and cheaper development of the software on the TI OMAP. This is much closer to the HSMM model of MEP than the custom-hardware model of MEP. While some progress has been made on hardware, I'd like to experiment with a solution that is more off-the-shelf. For one thing, the cost is quite competitive. A WRT54GL is $60. A Beagleboard is #149. USB to Ethernet conversion cable ranges in price from $10 to $25, depending on speed.

USB is not the best interface for our application, but it is the interface available on a stock beagleboard. However, there is an improvement available. The BeagleBuddy Zippy Ethernet Combo Board is an $80 expansion board for the BeagleBoard that adds the following:

* Battery Backed RTC
* Second MMC slot
* 10BaseT Ethernet
* Second RS-232
* +5V level I2C
* AT24 EEPROM

This eliminates USB in the path to the router. We have one Zippy board here at the lab, currently used on a project to set up a spectrum survey for 70cm.

Revision 5 of the test code tutorial for the NEON processor was released, and this revision is a candidate for the final version of the document. It can be found here:
http://www.delmarnorth.com/microwave/requirements/testcodetutorial_neon-test_draft5.pdf

It's also in the RSS feed, so it will automagically appear in your feed reader if you have subscribed to the project feed.

Next step is to add NEON support to Fastest Fourier Tranform in the West library. This project will improve signal processing on the beagleboard.

For further reading and reference, here are some web pages for the devices and software mentioned today.

Fastest Fourier Tranform in the West: http://www.fftw.org/

BeagleBuddy Zippy: http://www.tincantools.com/product.php?productid=16147&cat=249&page=1

Beagleboard Home Page: http://beagleboard.org/

WRT54GL router: http://en.wikipedia.org/wiki/Linksys_WRT54G_series#WRT54GL

OpenWRT: http://www.openwrt.org/

More soon,
-Michelle W5NYV

Neon-test Test Code Tutorial Draft 5

Here is draft 5 of the neon test code tutorial, for review and critique.

Neon-test Test Code Tutorial Draft 4