Date   

Re: Error compiling dv3000d for NWDigital DV3000 AMBE board

jim@...
 

Haven't received mine yet, so haven't downloaded the code, but on first glance, I'd think the -march setting you'd want is...

-march=armv6



Error compiling dv3000d for NWDigital DV3000 AMBE board

Bob Nielsen <n7xy@...>
 

I received my DV3000 yesterday and have installed it in my Raspberry PI running Rasbian (Debian wheezy-based Linux). I installed libwxgtk2.8-dev and portaudio19-dev. Following the instructions in http://nwdigitalradio.com/preparing-the-raspberry-pi-for-dv3000-applications/dv3000d I copied AMBETools-20140519 to my home directory and unzipped it. However, when I try to compile, I get the following error:

n7xy@raspberrypi ~/AMBETools $ make
make -C Common
make[1]: Entering directory `/home/n7xy/AMBETools/Common'
g++ -g -O2 -Wall -Wno-non-virtual-dtor -Wno-strict-aliasing -march=x86-64 -DDATA_DIR='"/usr/local/etc"' -DBIN_DIR='"/usr/local/bin"' -I/usr/lib/arm-linux-gnueabihf/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c AddressTextCtrl.cpp
cc1plus: error: bad value (x86-64) for -march switch
make[1]: *** [AddressTextCtrl.o] Error 1
make[1]: Leaving directory `/home/n7xy/AMBETools/Common'
make: *** [Common/Common.a] Error 2

Any thoughts?

73, Bob N7XY


DV3000 AMBE card

Bob Nielsen <n7xy@...>
 

On May 21, 2014, at 6:47 PM, Yahoo Groups <notify@...> wrote:


My card arrived today (that was fast, but it helps to be in northwest WA). It’s going to take a bit of reading before I am able to use it but hopefully I’ll have it going in a few days. I wish the GPIO headers on both boards were a bit shorter so it would fit inside my RPi case, but that’s a minor nit, since I will be moving it to the UDRX-440 when that ships.


Bob, N7XY


Re: [pcrepeatercontroller] DV3000 Info

myyahoo@...
 

In that case, a simple USB<->Serial converter might work?

These are cheap and commonly available for working with microcontrollers (e.g., Arduinos in 'bare' form).

- Richard, VE7CVS


Re: [pcrepeatercontroller] DV3000 Info

"John D. Hays" <john@...>
 

Hi Adrian,

We don't currently have any plans to offer the DV3000 in a USB or other factor.

However, as Jonathan points out.  The implementation of the dv3000d on the Raspberry Pi (and hopefully the Banana Pi) makes the device available over a network using UDP without some of the issues and headaches of the USB interface.

The GPIO interface is to a simple UART  (Gnd, V+, TX, RX, RTS) and if you can match the voltage and baud rate, then interfacing with other processors and adapters is pretty straightforward. 


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  





On Wed, May 21, 2014 at 7:32 AM, Adrian <vk4tux@...> wrote:
John as a DV3000 customer , I am interested in using the DV3000 not only on the Banana/raspberry Pi's but
as a usb dongle with some help from a adapter like this ;


DV3000 Info

"John D. Hays" <john@...>
 


DV3000 & The 20140519 beta release of the AMBE Tools

"John D. Hays" <john@...>
 

Ordering: http://nwdigitalradio.com/shop
Data Sheet: http://nwdigitalradio.com/wp-content/uploads/2012/04/DV3000DS.pdf

Under Raspbian, prepare your board with the following changes (and reboot)

Modify /boot/cmdline.txt:
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
# dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Add to /boot/config.txt:
# Speed up UART, set 16x max baud rate
init_uart_clock=3686400

Comment out in /etc/inittab:
#Spawn a getty on Raspberry Pi serial line
# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

More documentation to follow.

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  






---------- Forwarded message ----------
From: naylorjs@... [ircDDBGateway] <ircDDBGateway@...>
Date: Mon, May 19, 2014 at 8:56 AM
Subject: [ircDDBGateway] The 20140519 beta release of the AMBE Tools
To: ircDDBGateway@...


 

Hi Folks

As promised at Dayton here are the new AMBE Tools programs. One of them, DVToolReader was included elsewhere, but has now been upgraded considerably.

This suite consists of six programs, two are GUI based, DVToolReader and DVToolWriter and the rest are command line. All can work with either the DV-Dongle or the new DV3000 from NW Digital Radio. At their root these programs are designed to convert audio data to and from WAV files to either .dvtool files for the VoiceTransmit program, or for the announcements within the repeater, or to .ambe files for creating your own "Linked to" announcement, or even time ones. In all cases the WAV files should be mono and sampled at 48000 samples/sec.

The settings for wav2ambe and wav2dvtool are taken from DVToolWriter, and for ambe2wab and dvtool2wav from DVToolReader.

In addition DVToolWriter can record a microphone straight to these file formats.

Like the newly released Dummy Repeater, these programs can use the DV3000 which is hosted on a Raspberry Pi, and the same comments about the dv3000d running on the RPi apply.

For some reason, I can't upload my files to Berlios so the only source for the software is currently via this group.

Jonathan  G4KLX




New Product from NW Digital Radio

"John D. Hays" <john@...>
 

Dayton Hamvention

NW Digital Radio announced, today, immediate availability of the DV3000 AMBE card. 


There is a Hamvention special for $89.00, which will be honored for 1 month or until current inventory is exhausted (about 100, er make that 90 units).  You may purchase at http://nwdigitalradio.com/shop 

This is the same card that will be used in the UDRX-440 but may be used with the Raspberry Pi.

Jonathan Naylor has adapted DummyRepeater and several wav / AMBE conversion utilities, which will be in his next beta release (Monday or Tuesday).

SVN users can get the code now, but there is a minor change that will be necessary.


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Testing Resources

Mike Heitmann <n0so@...>
 



Watch for some news from Dayton on Friday.  [ Sorry, it will not be that UDRX-440s are shipping :( ]




Hopefully someone will post the news here for those of us unfortunate enough to not make it to Dayton this year ( Granddaughters First birthday party for this OM ).

Mike, N0SO 


Re: Testing Resources

"John D. Hays" <john@...>
 

Hi Paul,

Some very thought provoking ideas.

These are good tools for the community to start thinking about.  To that end, it is our plan for the API to include socket access to the modem, as well as many of the system metrics that would aid such tools.  As a small company, we will not be able to develop every tool that the community will want or need, but will support developers who wish to undertake their creation -- part of our commitment to an open architecture.

The processor is capable of running Python, C, JavaScript/NodeJS, etc. using standard Debian Linux interfaces and tools.

As we prepare for Dayton, our schedules will be pretty busy through the rest of the week.

Watch for some news from Dayton on Friday.  [ Sorry, it will not be that UDRX-440s are shipping :( ]


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  





On Tue, May 13, 2014 at 3:26 PM, Paul Johnson ve7dhm@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Brian,

The remote location may or may not have internet access.

The general concern for me is how do I prove that the initial
installation is good - the grounding, cabling, connections etc - then
add the RF emitter, and then the RF path - so that when I walk away from
a remote site installation I only have to be concerned about the RF
path.

I would like to see some general usage installation tools which would
provide a "good to go" check list. This means being able to locally
loop back a few megabits of data with no errors and then do the same
end to end over the RF path. Not all installations will be created
equally and it would be nice to be able to identify where data link
errors are injected into the UDR-X network...is it the installation or
the RF path?

I have used a Firebird and Fluke network equipment to do end to end
testing and I thought there must be software applications that can also
do some of the testing done with such equipment checking "keyboard to
antenna".

It is my understanding that the UDR-X is not full duplex so looping back
from RF output to RX input, using a RF signal sampler - Microlab / FXR
type - is not possible. So, the alternative is to use two UDR-X units
which adds additional complexity to the testing procedure but is better
than nothing.
The ability of the modem and emitter to operate full duplex certainly is
the ideal local test procedure without having to "go on the air". Using
two UDR-Xs would accomplish the same goal.

For end to end testing over the RF path here again full duplex would be
ideal. However, something similar could be accomplished by a store and
forward application running at the remote end. The local end would TX a
data stream of N bits and the remote end store and then TX back the bit
stream to the local end. A checksum, SNR, BER, and constellation
display application would give RF path quality.

There seems to be quite a bit of info on the internet regarding python,
ipython, matlablib, SNR, BER and linux. So, if the UDR-X computer is up
to the task then the possibility of general usage installation apps
running on it to test an installation looks promising....or maybe adding
a Raspberry Pi might also work.

Lots of things to think, do and have fun with (;

Looking for ideas....

Paul VE7DHM




Re: Testing Resources

Paul Johnson <ve7dhm@...>
 

Brian,

The remote location may or may not have internet access.

The general concern for me is how do I prove that the initial
installation is good - the grounding, cabling, connections etc - then
add the RF emitter, and then the RF path - so that when I walk away from
a remote site installation I only have to be concerned about the RF
path.

I would like to see some general usage installation tools which would
provide a "good to go" check list. This means being able to locally
loop back a few megabits of data with no errors and then do the same
end to end over the RF path. Not all installations will be created
equally and it would be nice to be able to identify where data link
errors are injected into the UDR-X network...is it the installation or
the RF path?

I have used a Firebird and Fluke network equipment to do end to end
testing and I thought there must be software applications that can also
do some of the testing done with such equipment checking "keyboard to
antenna".

It is my understanding that the UDR-X is not full duplex so looping back
from RF output to RX input, using a RF signal sampler - Microlab / FXR
type - is not possible. So, the alternative is to use two UDR-X units
which adds additional complexity to the testing procedure but is better
than nothing.
The ability of the modem and emitter to operate full duplex certainly is
the ideal local test procedure without having to "go on the air". Using
two UDR-Xs would accomplish the same goal.

For end to end testing over the RF path here again full duplex would be
ideal. However, something similar could be accomplished by a store and
forward application running at the remote end. The local end would TX a
data stream of N bits and the remote end store and then TX back the bit
stream to the local end. A checksum, SNR, BER, and constellation
display application would give RF path quality.

There seems to be quite a bit of info on the internet regarding python,
ipython, matlablib, SNR, BER and linux. So, if the UDR-X computer is up
to the task then the possibility of general usage installation apps
running on it to test an installation looks promising....or maybe adding
a Raspberry Pi might also work.

Lots of things to think, do and have fun with (;

Looking for ideas....

Paul VE7DHM



Hi Paul,
When you say remote location, I assume you have no network access,
only RF

Looping 25W back into our receiver would be a bad idea. :) Looping the
modem
would just tell you the processor is running.
Do you mean more of a digipeater mode where received packets are
stored then
re-transmitted? We could disable checksum to guarantee a response for
analysis
locally.

As part of the Hi-Speed effort, we are building a channel sounder for
testing
purposes. This is a PN generator designed for analysis.
The easiest thing to do would be to put the remote UDR in sounder mode
and use
your local UDR to analyze the received data which includes RSSI and
BER.
Constellation is an internal design tool at this time, but we will
provide the
hooks to some enterprising WebGL folks for display.
The results could be logged locally. We could also run sounder as a
chron job
(telemetry or beacon) then you'd get results even if you couldn't
successfully
talk to the remote unit. A few second burst hourly would be
interesting.

Great topic. What if you had several internet connected UDRs receiving
results
for comparison?
I'd like more input, I think this topic has a lot of merit.
Bryan - K7UDR


Re: UniversalDigitalRadio

myyahoo@...
 

Yes, it's the RTL stick that I was thinking about (I have a few of these already). I'm interested in the high speed modes that are now being developed, rather than the existing 1.2 and 9.6 kbps low speed data modes.

Watching and (eagerly and maybe a little less than patiently?) awaiting release and delivery. :-)

- Richard, VE7CVS


Re: AW: UniversalDigitalRadio

"siegfried jackstien" <siegfried.jackstien@...>
 

Use an rtl stick (dvbt usb stick)

Then your favourite sr software (be it hdsdr, sdrharp or whatever)

Route the audio to "soundmodem" and you can receive 1k2 or 9k6 packet

Dg9bfc

Sigi

-----Ursprüngliche Nachricht-----
Von: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...]
Gesendet: Sonntag, 11. Mai 2014 16:28
An: UniversalDigitalRadio@...
Betreff: [UniversalDigitalRadio] Re: UniversalDigitalRadio



Would it be possible/practical to set up GNUradio and a cheap SAT-TV SDR
dongle as a quick, portable test set for the UDR's transmitter?

It would be receive-only, of course, but having half the test gear with
you is better than none. :-)

I could certainly be done in 'spectrum analyser' mode, but it would be
interesting to be able to at least receive and decode the beacons or
packets that are being sent.

- Richard, VE7CVS


Re: UniversalDigitalRadio

myyahoo@...
 

Would it be possible/practical to set up GNUradio and a cheap SAT-TV SDR dongle as a quick, portable test set for the UDR's transmitter?

It would be receive-only, of course, but having half the test gear with you is better than none. :-)

I could certainly be done in 'spectrum analyser' mode, but it would be interesting to be able to at least receive and decode the beacons or packets that are being sent.

- Richard, VE7CVS


Re: Testing resources

Steve <yahoo-udr@...>
 

Can someone please translate these question and response into a bit less tech-speak for the rest of us?

---------- Original Message ----------
[ Sent by bhhoyer@... [UniversalDigitalRadio] at 05/11/2014 08:07 AM ]

Hi Paul,

When you say remote location, I assume you have no network access, only RF.


Looping 25W back into our receiver would be a bad idea. :) Looping the modem would just tell you the processor is running.


Do you mean more of a digipeater mode where received packets are stored then re-transmitted? We could disable checksum to guarantee a response for analysis locally.


As part of the Hi-Speed effort, we are building a channel sounder for testing purposes. This is a PN generator designed for analysis.



The easiest thing to do would be to put the remote UDR in sounder mode and use your local UDR to analyze the received data which includes RSSI and BER. Constellation is an internal design tool at this time, but we will provide the hooks to some enterprising WebGL folks for display.


The results could be logged locally. We could also run sounder as a chron job (telemetry or beacon) then you'd get results even if you couldn't successfully talk to the remote unit. A few second burst hourly would be interesting.


Great topic. What if you had several internet connected UDRs receiving results for comparison?


I'd like more input, I think this topic has a lot of merit.


Bryan - K7UDR


Re: Testing resources

bhhoyer@...
 

Hi Paul,

When you say remote location, I assume you have no network access, only RF.

Looping 25W back into our receiver would be a bad idea. :) Looping the modem would just tell you the processor is running.

Do you mean more of a digipeater mode where received packets are stored then re-transmitted? We could disable checksum to guarantee a response for analysis locally.

As part of the Hi-Speed effort, we are building a channel sounder for testing purposes. This is a PN generator designed for analysis.

The easiest thing to do would be to put the remote UDR in sounder mode and use your local UDR to analyze the received data which includes RSSI and BER. Constellation is an internal design tool at this time, but we will provide the hooks to some enterprising WebGL folks for display.

The results could be logged locally. We could also run sounder as a chron job (telemetry or beacon) then you'd get results even if you couldn't successfully talk to the remote unit. A few second burst hourly would be interesting.

Great topic. What if you had several internet connected UDRs receiving results for comparison?

I'd like more input, I think this topic has a lot of merit.

Bryan - K7UDR


Re: Testing resources

ross@...
 

Hi Paul,

Get the transmitter to send a known pseudo-random bit sequence that has good autocorrelation properties (eg a maximal length sequence from a linear feed back shift register: https://en.wikipedia.org/wiki/Linear_feedback_shift_register).

This is not encryption because the LFSR tap settings will be published and known to all (just like the "scrambler" used in K9NG/G3RUH 9k6 FSK modems).

Use a correlator at the receiver to demodulate this signal. The output of the correlator will tell you if you have any multipath echos (and what magnitude & delay they are, so that you can implement adaptive channel equalisation...). After channel equalisation, you can also use the correlator to determine S/N by measuring the difference between the correlation level and the noise level.
This technology has been around a long time eg every 2G GSM repeater sends repeated 64bit pseudorandom "training sequences" so that your mobile phone can sync to the repeater and adaptively equalise multipath and STANAG 4285 uses 80 symbols taken from a LSFR to achieve the same goal on HF. Adaptive channel equalisation is also absolutely vital for old fashioned dial up modems to operate 9k6 ~ 56k kb/sec in a 3 kHz voice channel. I ain't no patent lawyer, but I believe that there is plenty of published prior art from long enough ago for the relevant patents to have expired by now.


I have attached a spreadsheet (libre/open office .ods) and a few old screenshots. "channel equaliser.PNG" shows the TX bits, the raw RX bits, and the equalised RX bits. "impulse response1.PNG" shows the correlation function of the TX bits, and what comes out of the correlator at the simulated receiver. "impulse response2.PNG" shows the simulated receive correlator and what comes out of a correlator after the channel equaliser.

Basically, it sends the STANAG 4285 sequence over a bad channel (SNR is adjustable and the FIR is to simulate multipath), then it uses the autocorrelation properties of the received '4285 sequence to attempt to correct the channel impulse response (multipath). As you decrease the S/N, you will see that the channel equalisation is degraded.



73
Ross Whenmouth ZL2WRW


New Posting on NW Digital Radio Blog

"John D. Hays" <john@...>
 

Turn your speakers on and listen to very weak signal CW running through the UDRX receiver.

http://nwdigitalradio.com/receiver-sensitivity


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  


Testing resources

ve7dhm@...
 

Looking for testing resources / testing methods for installed UDRs at remote sites.

- can the UDR be put into a loop back mode at the RF or modem stage remotely?

- constellation display application of RX data

- SNR / BER data for determining RF path quality

- anyone writing python code in support of UDR testing ?

In the PNW there will probably some long RF paths across water and it would certainly

help to have testing resources available to troubleshoot connection / data throughput

issues at initial UDR install and throughout the year as weather conditions change the

RF path.


Thanks for any feedback


Paul VE7DHM



Re: AW: PAVE/PAWS (Over-The-Horizon radar - shades of the woodpecker - in reverse!)

u4gh@...
 

I wasn't suggesting derailing the current radio release or altering it any way. I was thinking of 'next steps after 70cm is going'.

As to "we will do it if the customer asks" - I work at a major producer of network gear (yes, that one! :-) ) and I hear that same message all of the time. Unfortunately, that means that you're asking your current customer base - who, ostensibly, bought your product because it fits their need - to direct your product development. You generally only get incremental changes rather than innovative/revolutionary product growth that way.

These aren't the people who you need to ask about expanding the product - it's the people who did *not* buy your product because it did *not* fit their need that you need to ask. I've worked with several product groups to extend their product well beyond what their current customers wanted (because, as an 'enterprise customer' myself, I do know what bigger enterprises require), and I've helped grow sales into large, enterprise-class customers who would never have considered the product in its original state. (No, they don't send me a cut! :-( )

I'm acting as one of those customers "who has a need outside the scope of the current product" (although I still want the current product too!), as I can see that it's going to be a tougher sell across a lot of the southern states that are hit by PAVE PAWS. 219-220 MHz would be a good target here, as it is allocated (at least in Northern California) to high speed digital use. I'd forgotten that the synthesizer deck was limited to 1 GHz, and raising that (or messing with transverters) would be a much bigger project than a 220 MHz RF deck (says he who isn't designing the RF deck :-)). I know that this doesn't help those outside North America, though. (Seems that maybe a transverter option would be worth pursuing there?)

Those of us in the SF Bay Area or on the coast may be able to operate low level stations on 70 cm for now thanks to the hills between us and Beale AFB (where the local PAVE PAWS site is located), but anyone more inland from here (Pleasaton, Livermore, Vacaville, Sacramento and the Central Valley) are likely to run afowl of PAVE PAWS, even at low elevations. The details of what constitutes 'interference' are classified, so it is difficult for anyone to operate within range of one of these sites to avoid interference that they don't know that they are creating, and the danger is that the government could shut down the entire 70 cm band in the whole state if they have to handle interference issues (apparently this has been brought up already).

A finger-in-the-air test would be: how many people in the PAVE PAWS affected areas have signed up for a unit?

Once the current unit is going, how much work is involved in getting a 220 MHz deck going? My previous comment not withstanding (I'm nowhere near the RF guy that Dennis is!), I would be willing to tackle a first-round 220 MHz deck as an experimental project. This would in no way derail the current deployment, as the only resources that I would need would be a 70cm unit (which I'm waiting eagerly for the release of) and maybe an occasional question answered on this forum. I believe that I already have sufficient RF test gear to make this successful (and an impetus to gather more if needed :-) ).

If others are willing to help, the more the merrier. If you happen to be in range of my south San Jose station - all the better, we can work together over-the-air!

- Richard VE7CVS