Date   

Re: Porting Zephyr HCI Layer

ryan.kayesimmons@...
 

Hi Johan

Thank you for your quick reply.

Yes, as you mentioned and as I already understand, hci_uart is for separating the controller and host on different chips. 

In this situation, I need to run my own Bluetooth host stack on the nrf52840 (same chip) with some hci interface - Nordic does not supply this hci interface which is why I'm looking at Zephyr.

The difficulty here is that my Bluetooth host stack is using FreeRTOS.. so as you said, it would be easier to port Zephyr to my Bluetooth host stack than to port the Zephyr LL to FreeRTOS. 
That might be the only way to continue with my issue and to get full access to the hci & link layer? 

Kind Regards,
Ryan Kaye-Simmons




From: Hedberg, Johan <johan.hedberg@...>
Sent: Wednesday, January 15, 2020, 1:17 AM
To: ryan.kayesimmons@...
Cc: devel@...
Subject: Re: [Zephyr-devel] Porting Zephyr HCI Layer

Hi Ryan, On 14. Jan 2020, at 9.13, ryan.kayesimmons@... wrote: > I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? > on the same chip. That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between. > Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make? The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr. > I guess I just want to know if I’ll be wasting a lot of my time if I take this approach! I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa. Johan


Feedback requested on west manifest imports

Bolivar, Marti
 

Hello Zephyr users and developers,

We've just uploaded a pre-release version of west to PyPI with a new
feature: manifest imports. We would like your feedback!

For a short README you can follow to try it out, see:

https://github.com/mbolivar/my-zephyr-app

This new feature lets you import projects from a west.yml file
somewhere else (like zephyr/west.yml) into your own "downstream"
west.yml file.

The import gives you the zephyr repository and all its modules "for
free": you do not have to copy/paste projects from zephyr/west.yml into
your custom file and manually track changes. You can also add your own
repositories or override individual modules if you've got your own
forks, etc. See the README for links to more information.

Please let us know what you think. We'd like to get feedback before
the west 0.7 release, as making big changes after that time will be
harder to do.

Thanks!
Marti


Upcoming Event: Zephyr Project: APIs - Tue, 01/14/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 14 January 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will focus on a new RFC and GPIO.

- RFC: New counter_get_value() API call
- https://github.com/zephyrproject-rtos/zephyr/issues/21846

- GPIO: Update on progress
- Proposal from Peter Bigot: Port remaining users without testing them on hardware (accepted)
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Porting Zephyr HCI Layer

Johan Hedberg
 

Hi Ryan,

On 14. Jan 2020, at 9.13, ryan.kayesimmons@clarinox.com wrote:
I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS,
What do you mean by a “Host application”? A Bluetooth host application? Using what APIs?

on the same chip.
That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different chips, with a UART transport in between.

Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make?
The hci_uart application is a fairly light-weight piece of code that enables one of the possible HCI drivers in Zephyr and then adapts that to the standard UART HCI transport protocol. In the case of the nRF52840 the underlying HCI driver maps to the full native Bluetooth link layer of Zephyr, i.e. that’s where the bulk of the code is, and that’s tightly coupled to Zephyr.

I guess I just want to know if I’ll be wasting a lot of my time if I take this approach!
I’m left with many open questions based on your email, but I get the feeling you might want to explore the feasibility of porting your “host application” to Zephyr rather than vice-versa.

Johan


ARM Cortex-R user mode -- should system call handlers be running with external interrupts disabled?

Phil Erwin Jr
 

I've noticed that on ARM Cortex-R with user mode enabled, that when we enter the system call handlers, such as z_hdlr_k_str_out(), that interrupts are disabled.  It seems to me that external interrupts should be enabled during this time. 

In looking through the Cortex-M support, I don't see where interrupts are enabled there either, so I wanted to poll the community to ask what the expectations are: external interrupts enabled or disabled?

Phil


Porting Zephyr HCI Layer

ryan.kayesimmons@...
 

Hi there,

 

I am currently trying to port the Zephyr HCI UART example (for nrf52840_pca10056) to FreeRTOS but and am having some difficulties doing so. The reasoning behind this is that I want to run a Host application, that uses FreeRTOS, on the same chip.

 

Correct me if I’m wrong, but it looks like the Zephyr OS is tightly coupled with the HCI layer and would take a lot of time to decouple and replace with FreeRTOS – is this a fair statement to make?

I guess I just want to know if I’ll be wasting a lot of my time if I take this approach!

 

Thank you in advance for your response. 😃

 

Kind Regards,

Ryan Kaye-Simmons

 


Re: Pinmux override

Stefan Jaritz
 

Morning,

As Erwan was telling, IMHO the pinmux variant is a good solution. For example if you doing power saving, you might power down parts of you pcb. Just image the case that you have a peripheral communicating via USART. If it is powered down down you should also configure your stm UART pins, to prevent that you stm is powering the IC via the RX, TX lanes. So you need to do this pinmux stuff not only at boot time.

If you image the board startup as just one use case of pin config, because your firmware will have different ones (like production, self test, operational, error state) you can imagine that the generating a static config via dts is not working in most of the cases. For my stm32f4 platform you can perfectly handle pinconfig with the stm32 pinmux port.

for example:

static void uart3_dma_gpio(bool on) {
   const struct pin_config pin_on[] = {
        {STM32_PIN_PC5, STM32F4_PINMUX_FUNC_PC5_USART3_RX},
        {STM32_PIN_PB10, STM32F4_PINMUX_FUNC_PB10_USART3_TX},
        {STM32_PIN_PB13, (STM32_PINMUX_ALT_FUNC_8 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
        {STM32_PIN_PB14, (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
    };

    const struct pin_config pin_off[] = {
        {STM32_PIN_PC5, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB10, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB13, (STM32_MODER_ANALOG_MODE)},
        {STM32_PIN_PB14, (STM32_MODER_ANALOG_MODE)},
    };
    if (true == on) {
        stm32_setup_pins(pin_on, ARRAY_SIZE(pin_on));
    } else {
        stm32_setup_pins(pin_off, ARRAY_SIZE(pin_off));
    }
}

Stefan

On 11/01/2020 22:17, Marc Herbert wrote:

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@lists.zephyrproject.org> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like https://lists.zephyrproject.org/g/devel/topic/61321118



Re: Pinmux override

Marc Herbert
 

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@lists.zephyrproject.org> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like https://lists.zephyrproject.org/g/devel/topic/61321118


Re: Pinmux override

Vincent - VLoTech
 

Hi all,

Device trees are used during compile time within Zephyr. 
But what if you want to support several hardware revisions in the same binary? 
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years. 

How should that be managed within zephyr? As most drivers use the provided DT output...

Vincent van der Locht

Op 11 jan. 2020 om 16:35 heeft Erwan Gouriou <erwan.gouriou@...> het volgende geschreven:


Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


RFC: API: Counter: counter_read() has no way of indicating failure

Henrik Brix Andersen
 

Hi all,

Our current counter API has a function for reading the current counter value (counter_read()) which does not allow indicating read failure in a standard way.
I have submitted an RFC for introducing a new API function to resolve this and deprecate counter_read().

See https://github.com/zephyrproject-rtos/zephyr/issues/21846 for further details. Please comment on the RFC issue if you have any input on this.

The counter API is currently marked as an unstable API (see https://github.com/zephyrproject-rtos/zephyr/projects/15).

Best regards,
Brix
--
Henrik Brix Andersen


Re: Pinmux override

Erwan Gouriou
 

Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


Re: Pinmux override

Allen Curtis
 

I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


Re: Pinmux override

Erwan Gouriou
 

Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan


On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga




Pinmux override

Joris Offouga
 

Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports, but it is not defined in pinmux.c and I must thzn modify this file to add the I2C configuration. Is there a better way to do this without modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 01/09/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 9 January 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Dev-Review Meeting Agenda (Jan 9)

Kumar Gala
 

Here’s the agenda topics for this week:

* drivers: allow to retrieve device structure by the name prefix:
[ https://github.com/zephyrproject-rtos/zephyr/pull/21709 ]
* dt topics

If there’s anything else to add please let me know.

Thanks

- k


Re: [MQTT/SARAR4] Issue during MQTT publish

Guillaume Paquet
 

Hi Jukka,

 

Thanks for your answer.

I created issue here

https://github.com/zephyrproject-rtos/zephyr/issues/21764

 

I don’t assign it.

 

Rgds,

 

Guillaume

 

De : Jukka Rissanen <jukka.rissanen@...>
Envoyé : mercredi 8 janvier 2020 14:13
À : Guillaume Paquet <guillaume.paquet@...>; William.fish@...; devel@...
Objet : Re: [Zephyr-devel] [MQTT/SARAR4] Issue during MQTT publish

 

Hi Guillaume,

 

it sounds like sara modem driver has a regression. Could you create a bug report for this at

 

 

On Wed, 2020-01-08 at 12:43 +0000, Guillaume Paquet wrote:

Hello William,

 

Thanks for your feedback.

Yes please find below output in my console:

 

 

For your information, I achieved to make it works with previous revision of SARA R4 driver.
It does not work after the following commit : https://github.com/zephyrproject-rtos/zephyr/commit/ebf6520d8713aae9809eb1ef6bee7211cf9b4caa#diff-cb3c7d77935fa5df6ccb74a1c5e050ba

 

 

Can you please let me know if SARA R4 is tested on MQTT or just on LWM2M example ? (I did not try this last one because I have not any LWM2M server available).

 

I suspect that only LWM2M example was used for testing sara-r4 modem.

 

 

Cheers,

Jukka

 


Re: [MQTT/SARAR4] Issue during MQTT publish

Jukka Rissanen
 

Hi Guillaume,

it sounds like sara modem driver has a regression. Could you create a bug report for this at


On Wed, 2020-01-08 at 12:43 +0000, Guillaume Paquet wrote:

Hello William,

 

Thanks for your feedback.

Yes please find below output in my console:

 

 

For your information, I achieved to make it works with previous revision of SARA R4 driver.
It does not work after the following commit : https://github.com/zephyrproject-rtos/zephyr/commit/ebf6520d8713aae9809eb1ef6bee7211cf9b4caa#diff-cb3c7d77935fa5df6ccb74a1c5e050ba

 

 

Can you please let me know if SARA R4 is tested on MQTT or just on LWM2M example ? (I did not try this last one because I have not any LWM2M server available).


I suspect that only LWM2M example was used for testing sara-r4 modem.


Cheers,
Jukka


Re: [MQTT/SARAR4] Issue during MQTT publish

Guillaume Paquet
 

Hello William,

 

Thanks for your feedback.

Yes please find below output in my console:

 

SEGGER J-Link V6.48 - Real time terminal output

J-Link OB-SAM3U128-V2-NordicSemi compiled Jan  7 2019 14:07:15 V1.0, SN=682005484

Process: JLinkExe

[00:00:00.677,947] <inf> modem_ublox_sara_r4: Setting Modem Pins

[00:00:10.878,143] <inf> modem_ublox_sara_r4: ... Done!

[00:00:10.878,173] <inf> modem_ublox_sara_r4: Waiting for modem to respond

[00:00:25.453,521] <inf> modem_ublox_sara_r4: Manufacturer: AT+CGMI

[00:00:25.454,284] <inf> modem_ublox_sara_r4: Manufacturer: u-blox

[00:00:25.510,009] <inf> modem_ublox_sara_r4: Model: AT+CGMM

[00:00:25.511,474] <inf> modem_ublox_sara_r4: Model: SARA-R412M-02B

[00:00:25.567,169] <inf> modem_ublox_sara_r4: Revision: <log_strdup alloc failed>

[00:00:25.570,129] <inf> modem_ublox_sara_r4: Revision: <log_strdup alloc failed>

[00:00:25.625,823] <inf> modem_ublox_sara_r4: IMEI: <log_strdup alloc failed>

[00:00:25.627,380] <inf> modem_ublox_sara_r4: IMEI: <log_strdup alloc failed>

[00:00:25.776,062] <inf> modem_ublox_sara_r4: Waiting for network

[00:00:27.782,928] <inf> modem_ublox_sara_r4: RSRP: -1000

[00:00:29.790,222] <inf> modem_ublox_sara_r4: RSRP: -1000

[00:00:31.797,546] <inf> modem_ublox_sara_r4: RSRP: -88

[00:00:33.798,065] <inf> modem_ublox_sara_r4: Network is ready.

[00:00:33.798,248] <err> modem_ublox_sara_r4: NET_SOCKET_OFFLOAD must be configured for this driver

[00:00:33.798,248] <wrn> net_dns_resolve: Cannot initialize DNS resolver (-134)

***** Booting Zephyr OS build zephyr-v2.0.0-41-g94019097bb8c *****

[00:00:34.842,803] <inf> net_config: Initializing network

[00:00:34.842,864] <inf> net_config: IPv4 address: 83.166.154.87

attempting to connect: socket_id:0 left_bytes:4 err: 4

MQTT connect failed -111

socket_id:1 left_bytes:4 err: 4

 

I can see that Network connection is ok MQTT server is not reachable.

 

For your information, I achieved to make it works with previous revision of SARA R4 driver.
It does not work after the following commit : https://github.com/zephyrproject-rtos/zephyr/commit/ebf6520d8713aae9809eb1ef6bee7211cf9b4caa#diff-cb3c7d77935fa5df6ccb74a1c5e050ba

 

I also made some debug on UART bus and I saw something strange on +UUSORD unsolicited answer management

 

 

This section is working

AT+USOCR=6,47069

+USOCR: 1

OK

 

AT+USOCO=1,"83.166.154.87",1883

OK

 

AT+USOWR=1,30

@

+USOWR: 1,30

OK

+UUSORD: 1,4

 

AT+USORD=1,4

+USORD: 1,4,"20020000"

OK

 

AT+USOWR=1,2

@

+USOWR: 1,2

OK

+UUSORD: 1,2

AT+USORD=1,2

+USORD: 1,2,"D000"

OK

 

….

 

 

This section is not working and we can see that +UUSORD does not come at the good moment.

AT+USOCR=6

+USOCR: 0

 

OK

AT+USOCO=0,"83.166.154.87",1883

OK

AT+USOWR=0,30

@

+USOWR: 0,30

 

OK

AT+USOWR=0,30

@

+USOWR: 0,30

 

OK

AT+USOWR=0,30

@

+USOWR: 0,30

 

OK

 

+UUSORD: 0,4

AT+USOWR=0,30

@

+CME ERROR: 3

 

 

Can you please let me know if SARA R4 is tested on MQTT or just on LWM2M example ? (I did not try this last one because I have not any LWM2M server available).

 

I hope my mail is clear enough (I know it is a bit long 😊)

 

Really thanks for your help

 

Rgds

 

Guillaume

 

De : devel@... <devel@...> De la part de William Fish via Lists.Zephyrproject.Org
Envoyé : mercredi 8 janvier 2020 12:06
À : devel@...
Cc : devel@...
Objet : Re: [Zephyr-devel] [MQTT/SARAR4] Issue during MQTT publish

 

Hi Guillaume,
Do you have the debug output showing

  • The R4 connection to network?
  • Connection to MQTT server?

At first glance it appears that you aren't connected (Err 111: Connection refused).

This could be caused by a number of things. You may find that there have been some configuration changes in the SARA driver which could be effecting your connection.

Billy..

1481 - 1500 of 8113