Date   
Re: MMDVM & UDRC

Annaliese McDermond
 

Thanks Johnathan. I’ll be working a things a bit today and this evening.

On Dec 8, 2018, at 12:36 PM, Jonathan Naylor via Groups.Io <naylorjs=yahoo.com@groups.io> wrote:

Hi Annaliese

I've done the changes to use a 48 kHz sample rate with the MMDVM-UDRC. I'm making no guarantees but the values are based on the working 48 kHz branch of the main MMDVM firmware. The only area that bothers me is the output level for POCSAG which may be very out compared to the others.
I’ll mainly be concentrating on D-STAR, YSF and DMR since that’s what I have test gear for.

This version should at least allow you to test with the UDRC and iron out any bugs.

I'd be very interested in any problems you find, and of course any pull requests that you may make to fix them.
I have a serial code fix for the read side of things. The transplanted MMDVMHost code has different semantics than the code for MMDVM-UDRC expects. The MMDVMHost code blocks when it receives an initial chunk of data and then waits indefinitely until it reads the entire buffer length requested. This doesn’t work for MMDVM-UDRC because it blocks the main event thread waiting for more serial data that will never come.

I did some significant remodeling of the serial input code so that it reads a little bit more judiciously and uses the length field of the MMDVM frame to figure out how much to ask the OS to read for it. This seems to solve the problem. I’ll PR it soon so you can at least take a look at it.

Remember that the DMR in this version is simplex only. Using the UDRC or similar hardware makes it impossible to have the type of synchronisation that duplex DMR repeating requires.
I understand the synchronization issues surrounding the DMR time slots. I’d like to get the rest of the protocols working correctly and then Bryan and I have had recurring ideas on how we could potentially deal with that issue. I’m curious, though, how tight is the timing issue time-wise. Does the PTT have to cycle in 1ms, 10ms, 100ms? I’m assuming it’s the time from the preamble in that slot to when actual data begins to flow.

Jonathan G4KLX
--
Annaliese McDermond (NH6Z)
Xenotropic Systems
mcdermj@...




On Friday, 7 December 2018, 10:18:47 GMT, Annaliese McDermond <nh6z@...> wrote:
On Dec 7, 2018, at 12:14 AM, Jonathan Naylor via Groups.Io <naylorjs=yahoo.com@groups.io> wrote:

Hi Annaliese

There are a set of filter coefficients for 48 kHz sample rate in a branch of the MMDVM firmware. I’ll look into slotting those in and altering the other variables.

Ideally I’d recalculate them in MATLAB as floating point but my license for it ran out. Octave can probably do it though. Even rescaling from Q15 format will probably give enough precision.
If you have some matlab code, I have a Matlab 2015b license on my Mac that I could spit out the coefficients for you. I’m mildly familiar with the process because I’ve done it for filter coefficients in the OpenHPSDR FPGA code that I was playing with.


It’s bizarre seeing Linux kernel AX25 being mentioned. I wrote that stuff 23 years ago and last looked at it 20 years ago. I’m not sure I could add anything to that discussion these days.

Jonathan G4KLX
--
Annaliese McDermond (NH6Z)
nh6z@...



Re: Compass udrc kernel panic

f6bvp
 

To Jonathan Naylor via Groups.Io <naylorjs=yahoo.com@groups.io>

Hi Jonathan,

I contact you through nw-digital-radiogroups for the reason that we are
facing a kernel panic while using ROSE kernel module.
I am glad to see you are still involved in digital communications.
Of course, as you mentionned, it's been a while since you have been
involved in packet radio AX.25 development and peculiarly in the code we
are interested in here.

There is a part of the code causing kernel panic that I identified but I
don't really understand what is its purpose.

Here is the kernel panic context.

-------- Message transféré --------
Sujet : [ROSE] rose dereferenced pointer kernel panic
Date : Sat, 8 Dec 2018 16:17:02 +0100
De : f6bvp <f6bvp@...>
Pour : David Ranch <dranch@...>, Basil Gunn
<@basil860>, Ralf Bächle DL5RB <ralf@...>, Richard
Stearn <richard@...>
Copie à : C Schuman <k4gbb1@...>, linux-hams@...,
Annaliese McDermond <mcdermj@...>, Bernard Pidoux
<bernard.pidoux@...>

Hi All,

While running packet radio network switch ROSE node a kernel panic
occurs systematically when opening a Chromium session.

kernel is 4.14.79-v7+ on a Raspberry Pi with Compass Linux (Debian stretch).

According to Kernel message panic is related to ax25cmp() performed with
a null pointer argument.

The function from which ax25cmp() gets a NULL pointer is rose_route_frame().
Function rose_route_frame() is called by rose_xmit() in the following
code sequence with explicit NULL pointer argument :

if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}

In order to avoid fatal ax25cmp() comparison we could use the following
rose_route_frame patch that has been already proposed by a number of
observers facing such dereferenced pointer.

diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 452bbb38d943..8f2f1fb1707d 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -863,6 +863,10 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
*ax25)
int res = 0;
char buf[11];

+ if (ax25 == NULL) {
+ return res;
+ }
+
if (skb->len < ROSE_MIN_LEN)
return res;
frametype = skb->data[2];

I actually patched rose module kernel 4.14.79-v7+ on
my Raspberry Pi and it succeeded in preventing kernel panic.

However, this is not satisfactory as the code sequence calling
rose_route_frame with a NULL argument should certainly have been written
on purpose. My concern is that I don't understand the significance of
this code in case it would not trigger a kernel panic. Is this a bug ?
Instead of NULL argument, did the author want actually to send an empty
value ?

Richard Stearn explained formerly :
https://marc.info/?l=linux-hams&m=146866282201792&w=2
"Calling rose_route_frame with a NULL ax25 callback parameter indicates
a locally generated frame. The existing code does not handle the NULL
value and the kernel hard crashes in an interrupt, resulting in the
system stopping processing."

Francois Romieu in 2016 suggested to ask you what you meant when you
wrote rose_rebuild_header (since that's where Eric B. took rose_xmit
from) back in the 2.1.9 era ?
https://marc.info/?l=linux-netdev&m=145720784703135&w=2

I know this was written long time ago but I wonder if you could give me
some explanations about what the code is supposed to do and how we could
keep it and avoid kernel panic at the same time.

Regards,

Bernard Pidoux, f6bvp

locked DRAWS Questions

WA7SKG <wa7skg@...>
 

Sorry, I've been kind of slow keeping up with the DRAWS thing. From a quick scan, I see that it interfaces with two radios, has built in GPS and can do digital with any Linux software that will run on a RaspberryPi. So, I am guessing that includes fldigi for MT63/PSK31/etc. and Xastir for APRS and, hopefully something for SSTV.

My plan is to use this mobile on my RPi 3 B+ which is on a standard Pi Touch 7" touch screen. Right now, I have a TNC-Pi connected and a Y-cable that powers the RPi and the touchscreen. The RPi powers the TNC-Pi through the header. It looks like the DRAWS has a 12V input that powers the RPi. Will this also power the touchscreen? How precise must the 12V input be? Can it handle the variations of vehicle voltage, which could swing from 10-14 volts?

My mobile radios are an Icom IC-7100 and a Yaesu FT-8900. It looks like I should simply be able to plug generic 6-pin DIN cables between the DRAWS and the data ports on the radios.

Looking on the NW Digital web page, it looks like they are taking orders for the next run of DRAWS. I'd like to get a warm fuzzy my plans are viable so I can go ahead and place an order.

tnx es 73,
Michael WA7SKG

Re: Show US Your DRAW Photos

William Franzin
 

Hey folks. I went shopping for my kids tonight and found the perfect DRAWS Pi setup. 

Check out this kids toy! - which is on sale in Canada for $150 CAD for another 1h45 min at BestBuy.

It's a Pi3 kit with battery pack, 1280x800 LCD, wireless keyboard, USB hub etc. This is perfect. 


On Thu, Nov 29, 2018 at 12:30 AM Basil Gunn <basil@...> wrote:

I gave the wrong url for the Sunfounder displays that I've used.
These are the correct urls for the 7" & 10" LCD displays.

https://www.sunfounder.com/7-inch-hdmi-lcd.html
https://www.sunfounder.com/10-1-inch-hdmi-lcd.html

One more feature that I like is they run on 12V.
/Basil

Basil Gunn <basil@...> writes:

>> I just realized they made the same mistake on the DRAWS as they did on the UDRC series.
>
> Not really a mistake if you use the superior SunFounder 7" monitor
> (1024x600) which would have the HAT cables come out the top.
> https://www.amazon.com/SunFounder-Inch-Monitor-HDMI-Raspberry/dp/B073GYBS93/ref=sr_1_4
>
> I personally prefer the Sunfounder 10" display with 1280x800 resolution
> that allows enough screen real estate to run a mail client or
> Xastir. With the 10" screen the cables face the bottom but the RPi is
> mounted at the top of the display with plenty of room for the cables.
>
> The 7" & 10" Sunfounders come with a built in speaker, RPi mounting
> pieces & an HDMI cable to mate with the RPi. I believe (could be wrong)
> both sizes come with a touch screen option.
>
> The 800x400 Smart-Pi display was good for my console winlink apps, mutt
> with paclink-unix, but really didn't cut it for anything with a gui.
>
> /Basil
>
>
>> The mini-din connectors are on the same side as they were on the UDRC. This means if you try to use one on the "Smarti-Pi" cases with the touchscreen and hinged base the cables will be in the way just like they are with the UDRC.
>>
>> Oh well looks like I will have to remove the connectors like I did on the UDRC2
>
> Or just buy a better video screen.
>
> /Basil n7nix




Re: Compass udrc kernel panic

Jonathan Naylor
 

Hi Bernard


To be honest I remember very little about the ROSE implementation. It was over twenty years ago, and I haven't revisited since. I'm pretty sure I handed over maintenance to someone else. As such I can't really help you, I've moved on to other projects which take all my time and I don't feel minded to dig into such old code. Surely it's more of a case that the software calling it should be modified to not do so, or maybe someone else would like to have a look.

I'm sorry to be evasive, but my input is about as useful as someone else's after this amount of time.

Jonathan  G4KLX


On Saturday, 8 December 2018, 23:33:08 GMT, f6bvp <f6bvp@...> wrote:


To Jonathan Naylor via Groups.Io <naylorjs=yahoo.com@groups.io>

Hi Jonathan,

I contact you through nw-digital-radiogroups for the reason that we are
facing a kernel panic while using ROSE kernel module.
I am glad to see you are still involved in digital communications.
Of course, as you mentionned, it's been a while since you have been
involved in packet radio AX.25 development and peculiarly in the code we
are interested in here.

There is a part of the code causing kernel panic that I identified but I
don't really understand what is its purpose.

Here is the kernel panic context.

-------- Message transféré --------
Sujet : [ROSE] rose dereferenced pointer kernel panic
Date : Sat, 8 Dec 2018 16:17:02 +0100
De : f6bvp <f6bvp@...>
Pour : David Ranch <dranch@...>, Basil Gunn
<basil@...>, Ralf Bächle DL5RB <ralf@...>, Richard
Stearn <richard@...>
Copie à : C Schuman <k4gbb1@...>, linux-hams@...,
Annaliese McDermond <mcdermj@...>, Bernard Pidoux
<bernard.pidoux@...>

Hi All,

While running packet radio network switch ROSE node a kernel panic
occurs systematically when opening a Chromium session.

kernel is 4.14.79-v7+ on a Raspberry Pi with Compass Linux (Debian stretch).

According to Kernel message panic is related to ax25cmp() performed with
a null pointer argument.

The function from which ax25cmp() gets a NULL pointer is rose_route_frame().
Function rose_route_frame() is called by rose_xmit() in the following
code sequence with explicit NULL pointer argument :

        if (!rose_route_frame(skb, NULL)) {
                dev_kfree_skb(skb);
                stats->tx_errors++;
                return NETDEV_TX_OK;
        }

In order to avoid fatal ax25cmp() comparison we could use the following
rose_route_frame patch that has been already proposed by a number of
observers facing such dereferenced pointer.

diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 452bbb38d943..8f2f1fb1707d 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -863,6 +863,10 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
*ax25)
    int res = 0;
    char buf[11];

+    if (ax25 == NULL) {
+        return res;
+    }
+
    if (skb->len < ROSE_MIN_LEN)
        return res;
    frametype = skb->data[2];

I actually patched rose module kernel 4.14.79-v7+ on
my Raspberry Pi and it succeeded in preventing kernel panic.

However, this is not satisfactory as the code sequence calling
rose_route_frame with a NULL argument should certainly have been written
on purpose. My concern is that I don't understand the significance of
this code in case it would not trigger a kernel panic. Is this a bug ?
Instead of NULL argument, did the author want actually to send an empty
value ?

Richard Stearn explained formerly :
https://marc.info/?l=linux-hams&m=146866282201792&w=2
"Calling rose_route_frame with a NULL ax25 callback parameter indicates
a locally generated frame.  The existing code does not handle the NULL
value and the kernel hard crashes in an interrupt, resulting in the
system stopping processing."

Francois Romieu in 2016 suggested to ask you what you meant when you
wrote rose_rebuild_header (since that's where Eric B. took rose_xmit
from) back in the 2.1.9 era ?
https://marc.info/?l=linux-netdev&m=145720784703135&w=2

I know this was written long time ago but I wonder if you could give me
some explanations about what the code is supposed to do and how we could
keep it and avoid kernel panic at the same time.

Regards,

Bernard Pidoux, f6bvp


locked Re: DRAWS Questions

Jack Spitznagel
 

Michael,

I will be interested to hear the NWD response to your question about fluctuations in power/mobile usage. The 12V line will not feed the display, you will need a separate 5V supply.

Experimenting now with a DRAWS, RPi 3B+, plus Raspberry 7" touch display mounted in a "SmartiPi Touch" display stand. This is all powered through the 5V "Y" microUSB adapter. I am using the stock 2.5A wall wart that Pi foundation supplies in their kits (probably groaning under load). I plan to change over to a higher capacity USB multiline charger when I find what I want. YMMV but this works for me.

KD4IZ
Jack Spitznagel
FM19oo

-----Original Message-----
From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of WA7SKG via Groups.Io
Sent: Saturday, December 8, 2018 09:13
To: main@nw-digital-radio.groups.io
Subject: [nw-digital-radio] DRAWS Questions

Sorry, I've been kind of slow keeping up with the DRAWS thing. From a quick scan, I see that it interfaces with two radios, has built in GPS and can do digital with any Linux software that will run on a RaspberryPi. So, I am guessing that includes fldigi for MT63/PSK31/etc.
and Xastir for APRS and, hopefully something for SSTV.

My plan is to use this mobile on my RPi 3 B+ which is on a standard Pi Touch 7" touch screen. Right now, I have a TNC-Pi connected and a Y-cable that powers the RPi and the touchscreen. The RPi powers the TNC-Pi through the header. It looks like the DRAWS has a 12V input that powers the RPi. Will this also power the touchscreen? How precise must the 12V input be? Can it handle the variations of vehicle voltage, which could swing from 10-14 volts?

My mobile radios are an Icom IC-7100 and a Yaesu FT-8900. It looks like I should simply be able to plug generic 6-pin DIN cables between the DRAWS and the data ports on the radios.

Looking on the NW Digital web page, it looks like they are taking orders for the next run of DRAWS. I'd like to get a warm fuzzy my plans are viable so I can go ahead and place an order.

tnx es 73,
Michael WA7SKG

Re: Show US Your DRAW Photos

Budd Churchward
 

Looking at the photo of the case from the rear, you can see that the Rpi header is occupied by a board with a connector coming from it. That is where you need to install the DRAWS board.
 

Sent: Saturday, December 08, 2018 10:18 PM
Subject: Re: [nw-digital-radio] Show US Your DRAW Photos
 
Hey folks. I went shopping for my kids tonight and found the perfect DRAWS Pi setup. 
 
Check out this kids toy! - which is on sale in Canada for $150 CAD for another 1h45 min at BestBuy.
 
It's a Pi3 kit with battery pack, 1280x800 LCD, wireless keyboard, USB hub etc. This is perfect.
 
 
On Thu, Nov 29, 2018 at 12:30 AM Basil Gunn <basil@...> wrote:

I gave the wrong url for the Sunfounder displays that I've used.
These are the correct urls for the 7" & 10" LCD displays.

https://www.sunfounder.com/7-inch-hdmi-lcd.html
https://www.sunfounder.com/10-1-inch-hdmi-lcd.html

One more feature that I like is they run on 12V.
/Basil

Basil Gunn <basil@...> writes:

>> I just realized they made the same mistake on the DRAWS as they did on the UDRC series.
>
> Not really a mistake if you use the superior SunFounder 7" monitor
> (1024x600) which would have the HAT cables come out the top.
> https://www.amazon.com/SunFounder-Inch-Monitor-HDMI-Raspberry/dp/B073GYBS93/ref=sr_1_4
>
> I personally prefer the Sunfounder 10" display with 1280x800 resolution
> that allows enough screen real estate to run a mail client or
> Xastir. With the 10" screen the cables face the bottom but the RPi is
> mounted at the top of the display with plenty of room for the cables.
>
> The 7" & 10" Sunfounders come with a built in speaker, RPi mounting
> pieces & an HDMI cable to mate with the RPi. I believe (could be wrong)
> both sizes come with a touch screen option.
>
> The 800x400 Smart-Pi display was good for my console winlink apps, mutt
> with paclink-unix, but really didn't cut it for anything with a gui.
>
> /Basil
>
>
>> The mini-din connectors are on the same side as they were on the UDRC. This means if you try to use one on the "Smarti-Pi" cases with the touchscreen and hinged base the cables will be in the way just like they are with the UDRC.
>>
>> Oh well looks like I will have to remove the connectors like I did on the UDRC2
>
> Or just buy a better video screen.
>
> /Basil n7nix




Re: Show US Your DRAW Photos

William Franzin
 

Correct. The stock power button is a pi hat connected to the usb battery pack. 

Based on the angle that also means the draws board should fit easily inside. I'm going to use a laser cutter on the side to cut holes for the mini din connectors. 

For power it appears the 2x18650 pack is configured something like a ups. For a home setup I think this will work well with just a little mod work. 

There's also enough room for the AMBE stick which I'll be using for transcoding. I'm working on voice control projects and will be using draws for digital voice. 

This is what I've been up to:


On Sun, Dec 9, 2018, 11:23 AM Budd Churchward <budd@... wrote:
Looking at the photo of the case from the rear, you can see that the Rpi header is occupied by a board with a connector coming from it. That is where you need to install the DRAWS board.
 
Sent: Saturday, December 08, 2018 10:18 PM
Subject: Re: [nw-digital-radio] Show US Your DRAW Photos
 
Hey folks. I went shopping for my kids tonight and found the perfect DRAWS Pi setup. 
 
Check out this kids toy! - which is on sale in Canada for $150 CAD for another 1h45 min at BestBuy.
 
It's a Pi3 kit with battery pack, 1280x800 LCD, wireless keyboard, USB hub etc. This is perfect.
 
 
On Thu, Nov 29, 2018 at 12:30 AM Basil Gunn <basil@...> wrote:

I gave the wrong url for the Sunfounder displays that I've used.
These are the correct urls for the 7" & 10" LCD displays.

https://www.sunfounder.com/7-inch-hdmi-lcd.html
https://www.sunfounder.com/10-1-inch-hdmi-lcd.html

One more feature that I like is they run on 12V.
/Basil

Basil Gunn <basil@...> writes:

>> I just realized they made the same mistake on the DRAWS as they did on the UDRC series.
>
> Not really a mistake if you use the superior SunFounder 7" monitor
> (1024x600) which would have the HAT cables come out the top.
> https://www.amazon.com/SunFounder-Inch-Monitor-HDMI-Raspberry/dp/B073GYBS93/ref=sr_1_4
>
> I personally prefer the Sunfounder 10" display with 1280x800 resolution
> that allows enough screen real estate to run a mail client or
> Xastir. With the 10" screen the cables face the bottom but the RPi is
> mounted at the top of the display with plenty of room for the cables.
>
> The 7" & 10" Sunfounders come with a built in speaker, RPi mounting
> pieces & an HDMI cable to mate with the RPi. I believe (could be wrong)
> both sizes come with a touch screen option.
>
> The 800x400 Smart-Pi display was good for my console winlink apps, mutt
> with paclink-unix, but really didn't cut it for anything with a gui.
>
> /Basil
>
>
>> The mini-din connectors are on the same side as they were on the UDRC. This means if you try to use one on the "Smarti-Pi" cases with the touchscreen and hinged base the cables will be in the way just like they are with the UDRC.
>>
>> Oh well looks like I will have to remove the connectors like I did on the UDRC2
>
> Or just buy a better video screen.
>
> /Basil n7nix




locked Re: DRAWS Questions

WA7SKG <wa7skg@...>
 

Jack,
How does the DRAWS work with the SmartiPi case? I saw some comments that there may be issues with the cables interfering with the stand. Not really a problem since I do not use the stand, I have mine on a VESA mount for mobile use. The DIN connectors should be okay, but the other connectors may be an issue. The pictures show two connectors on the left side. I guess one is for power, but I don't know what the other one is for.

I guess I'll need to run the RPi/DRAWS from the 12V lines and the touch screen from the 5V supply.

I do need to see the NWD response however on the 12V variations before I spend money on it.

73,
Michael WA7SKG


Jack Spitznagel wrote on 12/9/18 06:47:

Michael,
I will be interested to hear the NWD response to your question about fluctuations in power/mobile usage. The 12V line will not feed the display, you will need a separate 5V supply.
Experimenting now with a DRAWS, RPi 3B+, plus Raspberry 7" touch display mounted in a "SmartiPi Touch" display stand. This is all powered through the 5V "Y" microUSB adapter. I am using the stock 2.5A wall wart that Pi foundation supplies in their kits (probably groaning under load). I plan to change over to a higher capacity USB multiline charger when I find what I want. YMMV but this works for me.
KD4IZ
Jack Spitznagel
FM19oo
-----Original Message-----
From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of WA7SKG via Groups.Io
Sent: Saturday, December 8, 2018 09:13
To: main@nw-digital-radio.groups.io
Subject: [nw-digital-radio] DRAWS Questions
Sorry, I've been kind of slow keeping up with the DRAWS thing. From a quick scan, I see that it interfaces with two radios, has built in GPS and can do digital with any Linux software that will run on a RaspberryPi. So, I am guessing that includes fldigi for MT63/PSK31/etc.
and Xastir for APRS and, hopefully something for SSTV.
My plan is to use this mobile on my RPi 3 B+ which is on a standard Pi Touch 7" touch screen. Right now, I have a TNC-Pi connected and a Y-cable that powers the RPi and the touchscreen. The RPi powers the TNC-Pi through the header. It looks like the DRAWS has a 12V input that powers the RPi. Will this also power the touchscreen? How precise must the 12V input be? Can it handle the variations of vehicle voltage, which could swing from 10-14 volts?
My mobile radios are an Icom IC-7100 and a Yaesu FT-8900. It looks like I should simply be able to plug generic 6-pin DIN cables between the DRAWS and the data ports on the radios.
Looking on the NW Digital web page, it looks like they are taking orders for the next run of DRAWS. I'd like to get a warm fuzzy my plans are viable so I can go ahead and place an order.
tnx es 73,
Michael WA7SKG

locked Re: DRAWS Questions

 

Please follow this topic on the UDRC subgroup -- https://nw-digital-radio.groups.io/g/udrc/message/2148

locked Ras Pi3 B+ #draws

Robert KF6FOD
 

does it matter if you use a Pi 3B or B+ with the draws hat?

locked Re: Ras Pi3 B+ #draws

 

Either is fine.  (I also have one running on 3A+)

 

Follow-ups to the UDRC sub-group.

Re: NWDR's take on Raspberry Pi 3 Model A+?

 

Not an official endorsement or support, but I have a DRAWS HAT running on a 3A+ attached to a SmartiPi display.

DRAWS GPIO/Accessory connector #accessory #draws #adc

Ryan Reid
 

I'm not one much for understanding schematics, but I'm trying to figure out on the accessory connector you have an Ain2 and an Ain3. Are those auxiliary inputs, or analog inputs? I'm looking for an analog input so that I can monitor external battery voltage. And I'm not sure if the board has an ADC built into it or if I have to connect one externally.

Also I noticed on there that one of the pins is labeled rx and one is labeled tx.  Do those forward through to the serial port on the raspberry pi, or are they for something else?

Thank you,

Ryan
K1BLU

Re: DRAWS GPIO/Accessory connector #accessory #draws #adc

 



On Sun, Dec 16, 2018, 08:04 Ryan Reid <blupanthr2@... wrote:
I'm not one much for understanding schematics, but I'm trying to figure out on the accessory connector you have an Ain2 and an Ain3. Are those auxiliary inputs, or analog inputs? I'm looking for an analog input so that I can monitor external battery voltage. And I'm not sure if the board has an ADC built into it or if I have to connect one externally.

If you are monitoring the supply voltage, that is already handled on the 9-15 VDC input for powering the HAT (and Pi). 

There is also a second ADC exposed on the accessory jack. 

Also I noticed on there that one of the pins is labeled rx and one is labeled tx.  Do those forward through to the serial port on the raspberry pi, or are they for something else?

Those are for a serial port, it is /dev/ttySC1. The ttySC0 is to the GPS.


Thank you,

Ryan
K1BLU

Re: DRAWS GPIO/Accessory connector #accessory #draws #adc

 

image.png
I will let Anna or Bryan characterize the pins in more detail.


--


John D. Hays
Edmonds, WA
K7VE

   

Re: DRAWS GPIO/Accessory connector #accessory #draws #adc

Annaliese McDermond
 

On Dec 16, 2018, at 3:18 AM, Ryan Reid <@blupanthr2> wrote:

I'm not one much for understanding schematics, but I'm trying to figure out on the accessory connector you have an Ain2 and an Ain3. Are those auxiliary inputs, or analog inputs? I'm looking for an analog input so that I can monitor external battery voltage. And I'm not sure if the board has an ADC built into it or if I have to connect one externally.
The DRAWS has an ADC built into it. You are correct that those are brought out on pins “Ain2” and “Ain3”. You can access the values of these in a variety of ways through the lmsensors/hwmon (see https://github.com/lm-sensors/lm-sensors) subsystem in linux. If you type “sensors” on a running system, you’ll get something that looks like this:

ads1015-i2c-1-48
Adapter: bcm2835 I2C adapter
User ADC Differential: +0.00 V
+12V: +12.02 V
User ADC 1: +0.01 V
User ADC 2: +0.00 V

The “+12V” input is hooked to the DC input of the DRAWS. You can do various scaling on the User ADC values by using the sensors configuration file for DRAWS located at /etc/sensors.d/draws.

Note that there are also some scaling factors available as “dtparam” settings in config.txt.

These pins are also connected to pins 22 and 24 on the Broadcom SoC for doing digital inputs or outputs. Incidentally these are the “BCM” pin numbers. You’ll *never* hear me referring to wiringPi’s pin numberings.

I’ll let Bryan speak to the electrical characteristics of these pins, but I’m sure that if you try to measure a few thousand volts on them you’ll have a bad day.

Also I noticed on there that one of the pins is labeled rx and one is labeled tx. Do those forward through to the serial port on the raspberry pi, or are they for something else?
They do not connect to the /dev/ttyAMA0 port on the Pi. We don’t bring that out on draws. They connect to an additional serial port, /dev/ttySC1, which is on the I2C serial chip we use to access the GPS.

Thank you,

Ryan
K1BLU

--
Annaliese McDermond, J.D. (NH6Z)
nh6z@...

Re: DRAWS GPIO/Accessory connector #accessory #draws #adc

Ryan Reid
 

Thank you all!!

Just what I was looking for.

Ryan
K1BLU

On Sun, Dec 16, 2018, 09:32 Annaliese McDermond <nh6z@... wrote:


> On Dec 16, 2018, at 3:18 AM, Ryan Reid <blupanthr2@...> wrote:
>
> I'm not one much for understanding schematics, but I'm trying to figure out on the accessory connector you have an Ain2 and an Ain3. Are those auxiliary inputs, or analog inputs? I'm looking for an analog input so that I can monitor external battery voltage. And I'm not sure if the board has an ADC built into it or if I have to connect one externally.

The DRAWS has an ADC built into it.  You are correct that those are brought out on pins “Ain2” and “Ain3”.  You can access the values of these in a variety of ways through the lmsensors/hwmon (see https://github.com/lm-sensors/lm-sensors) subsystem in linux.  If you type “sensors” on a running system, you’ll get something that looks like this:

ads1015-i2c-1-48
Adapter: bcm2835 I2C adapter
User ADC Differential:  +0.00 V 
+12V:                  +12.02 V 
User ADC 1:             +0.01 V 
User ADC 2:             +0.00 V 

The “+12V” input is hooked to the DC input of the DRAWS.  You can do various scaling on the User ADC values by using the sensors configuration file for DRAWS located at /etc/sensors.d/draws.

Note that there are also some scaling factors available as “dtparam” settings in config.txt.

These pins are also connected to pins 22 and 24 on the Broadcom SoC for doing digital inputs or outputs.  Incidentally these are the “BCM” pin numbers.  You’ll *never* hear me referring to wiringPi’s pin numberings.

I’ll let Bryan speak to the electrical characteristics of these pins, but I’m sure that if you try to measure a few thousand volts on them you’ll have a bad day.

> Also I noticed on there that one of the pins is labeled rx and one is labeled tx.  Do those forward through to the serial port on the raspberry pi, or are they for something else?

They do not connect to the /dev/ttyAMA0 port on the Pi.  We don’t bring that out on draws.  They connect to an additional serial port, /dev/ttySC1, which is on the I2C serial chip we use to access the GPS.

> Thank you,
>
> Ryan
> K1BLU


--
Annaliese McDermond, J.D. (NH6Z)
nh6z@...




Re: DRAWS GPIO/Accessory connector #accessory #draws #adc

Ryan Reid
 

Maybe I'm missing something, but Sensors is not seeing it...
The hat is installed, and connected through the +12v Input.

root@compass:~# sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
root@compass:~#  sensors-detect
# sensors-detect revision 6284 (2015-05-31 14:00:33 +0200)
# Kernel: 4.14.79-v7+ armv7l
# Processor: ARMv7 Processor rev 4 (v7l) (//)
 
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.
 
Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): yes
modprobe: FATAL: Module cpuid not found in directory /lib/modules/4.14.79-v7+
Failed to load module cpuid.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No
 
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): yes
Sorry, no supported PCI bus adapters found.
 
Next adapter: bcm2835 I2C adapter (i2c-1)
Do you want to scan it? (YES/no/selectively): yes
Client found at address 0x18
Handled by driver `tlv320aic32x4_i2c' (already loaded), chip type `tlv320aic32x4'
    (note: this is probably NOT a sensor chip!)
Client found at address 0x48
Probing for `National Semiconductor LM75'...                No
Probing for `National Semiconductor LM75A'...               No
Probing for `Dallas Semiconductor DS75'...                  No
Probing for `National Semiconductor LM77'...                No
Probing for `Analog Devices ADT7410/ADT7420'...             No
Probing for `Analog Devices ADT7411'...                     No
Probing for `Maxim MAX6642'...                              No
Probing for `Texas Instruments TMP435'...                   No
Probing for `National Semiconductor LM73'...                No
Probing for `National Semiconductor LM92'...                No
Probing for `National Semiconductor LM76'...                No
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Probing for `NXP/Philips SA56004'...                        No
Probing for `SMSC EMC1023'...                               No
Probing for `SMSC EMC1043'...                               No
Probing for `SMSC EMC1053'...                               No
Probing for `SMSC EMC1063'...                               No
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No
Probing for `EDID EEPROM'...                                No
 
Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.
root@compass:~# uname -a
Linux compass 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

Re: DRAWS GPIO/Accessory connector #accessory #draws #adc

Ryan Reid
 

Answered my own question... forgot to change dtoverlay from udrc to draws.