xcsoar-devel — Development discussions for XCSoar. Mostly version 5 stuff.

Re: [Xcsoar-devel] Release 7.24

[Helmut R. <hel...@we...>]

Hey,

finally got an apk build with our dev instructions. Were missing to replace
the proper docker image in the proposed docker command.

Thx,

Helmut

Am Di., 2. Aug. 2022 um 14:15 Uhr schrieb Helmut Rohs <hel...@we...
>:

> Any progress on this? I would like to build/try some of the new features.
> Unfortunately I am not able to build the Android target with the described
> docker method, following the dev manual instructions.
> Is this the reason we don't see 7.24 builds being pushed?
> Any hint on this?
>
> Thx,
>
> Helmut
>

[Xcsoar-devel] Release 7.24

[Helmut R. <hel...@we...>]

Any progress on this? I would like to build/try some of the new features.
Unfortunately I am not able to build the Android target with the described
docker method, following the dev manual instructions.
Is this the reason we don't see 7.24 builds being pushed?
Any hint on this?

Thx,

Helmut

Re: [Xcsoar-devel] OTG Driver for FT4232 (USB to 4 port UART)

[Helmut R. <hel...@we...>]

Hi Henrik,

I anticipated the hub just to have a well supported port multiplier. No
need for the USB here, but USB/Serial dongles with smallest footprint and
all kind of voltage levels are available off the shelf. No need to solder
and tinker.

just my 2ct's

Helmut


Am Di., 12. Juli 2022 um 08:42 Uhr schrieb Henrik Bieler <
hen...@gm...>:

> Hello Helmut,
>
> thanks for you feedback.
>
> Am 11.07.22 um 11:28 schrieb Helmut J. Rohs:
> > I ended up trying multiple USB-hubs with varying success. Most
> > importantly the issue was to get power supplied to the Android at the
> > same time as OTG connectivity. An USB hub in principle does the job to
> > connect multiple devices in parallel very well. USB/RS232 converter
> > and the proper level shifter are available in any desired form. So I
> > would not look for a specific USB/RS232 adapter that comprises
> > multiple ports, rather than looking for the USB hub with just the
> > appropriate number of ports. All the hubs I tried worked perfectly in
> > terms of accomplishing the 1 to many (device) connectivity for the
> > XCS/Android display.
> >
>
> > My use case is as follows:
> >
> > XCS/Androis - connects to:
> > -> USB audio card
> > -> USB I-panel outlet (maybe a phone to charge, or a memory stick)
> > -> NMEA srteam from variometer
> > -> ACD/radio (to set frequencies)
> > <- and finally a DC/DC converter providing 5V
>
> I get your point. However for me right now I have less use for
> additional USB-Connectivity and need three or four RS232 interfaces, so
> i just think the solution with the 4-port FT4232 will provide for a
> cleaner setup in my case. If needed later on a USB-Hub could be added
> "on top".
>
> (The USB-audio sounds interesting, since I discarded some possible E-Ink
> Devices because they did not provide their own speaker audio)
>
>
> > This hub i.e.
> >
> https://www.amazon.de/-/en/gp/product/B07Z4RHJ2D/ref=ppx_od_dt_b_asin_image_s01?ie=UTF8&psc=1
> > does fine for the first four items. You just allocate the next
> > recognized RS232 dongle in XCS and configure it with the desired rates
> > and protocols.
> >
> > My observation on drawing power from the USB-C connector to the
> > Android have been not so successful. It work always as long as the
> > Android is switched off. Then the Android accepts power. For the
> > moment it uses the OTG connectivity the power drawing is refused. And
> > on top of this, just not always. Once the Android successful draws
> > power the adding of OTG connectivity does not interrupt the power
> > drawing.
> >
> This sounds like PD-Behaviour without a dedicated chip switching to the
> desired state. I think the PD-OTG-Power-Adapter must have such a chip
> built in.
> > Up to now I dont have a clue why that. It could be the specific design
> > of the Android ebook reader, it could be the PD protocol design, which
> > I dont know.
> >
> > I will try your suggested PD adapter and cascade it with my hub. You
> > might try to solve your multi port issue with a hub?!
> >
> For me i works perfectly. Independent of which part of the setup is
> switched on first.
>
> (Adding/Removing power while connected, will require a Device-reconnect
> in XCSoar, since the power to the FTDI is interrupted for a short moment
> when making the change)
>
>
> > We should definitely move this discussion to xcsoar on github. I think
> > this going digital in cockpits is of wide interest for many of us.
> >
> Ok. Good idea! I opened a ticket on github:
> https://github.com/XCSoar/XCSoar/issues/968
>
>
> Cheers Henrik
>
>
> > cheers
> >
> > Helmut
> >
> > Am 07.07.22 um 16:06 schrieb Henrik Bieler:
> >> Hello!
> >>
> >> After I announced my plan to make use of FT4232 to interface multiple
> >> RS232 Streams to XCSoar, I received requests from several people to let
> >> them know if I have success with this setup.
> >> I will give you you all a short summary on the status.
> >>
> >> Obviously the goal is to have power supplied TO the phone while at the
> >> same time the phone is acting as USB-(OTG-)-Host.
> >> This not trivial, but my research revealed that this should be possible:
> >>
> >> - on Micro-USB with a 124K pull down resistor on the ID line and **IF**
> >> the standard is correctly implemented by the phone firmware.
> >>   (I did not follow through on this method since I think MicroUSB will
> >> be obsolete soon)
> >>
> >> -on USB-C this seems ONLY be possible by making use of the
> >> PowerDelivery-Protocol (PD), which can be used to switch to the desired
> >> state. (Phone charging but acting as host)
> >>
> >> I found an USB-C adaptor which promises to do exactly that.
> >> https://de.aliexpress.com/item/1005003887696758.html
> >>
> >> And indeed this works (confirmed on a Pixel4a) ! =)
> >> However the phone needs to be able to "talk" PD. Just an
> >> USB-C-Receptacle is not sufficient.
> >>
> >> I am able to receive a Flarm-compatible NMEA Stream into XCSoar while
> >> charging the phone. =)
> >> (Caution: If you want to connect a real RS232 device you also need
> >> MAX(3)232 level shifters, or you can fry the FTDI)
> >>
> >> However there is some work to be done on the XCSoar side:
> >>
> >> On XCSoar on Linux the 4 Ports of the FTDI4232 are natively recognized
> >> as ttyUSB(0-3) and so all work as expected.
> >> However on Android the FTDI4232 shows up as only one device instead of
> >> four. It works, but only on the first channel.
> >>
> >> I am not a programmer. So could anyone help implementing the three
> >> remaining channels in XCSoar? Or at least point me to where to get
> >> started and maybe a general idea how to do it? I think this should not
> >> be too difficult for anyone familiar with that part of the code.
> >>
> >> If this can be made to work (which I am positive that it will), this
> >> will be a great new kind to interface all of our RS232 Streams in the
> >> Cockpit to XCSoar. (Flarm, Radio, ADS-B, Sensor-Board, SoftRF, ......)
> >>
> >> Hoping for your help!
> >> Henrik
> >>
> >>
> >>
> >>
> >> Am 21.06.22 um 10:58 schrieb Henrik Bieler:
> >>> Hey everyone,
> >>>
> >>>
> >>> my cockpit will need a major overhaul the next winter and i am
> >>> considering to replace my IOIO-OTG setup, which I am using to
> >>> connect to
> >>> FLARM, LXNano, and KRT2 with something more generic, since the
> >>> IOIO-Boards seem to be less available and getting no recent
> >>> development.
> >>>
> >>> I was considering to connect a USB-OTG Hub and 3 USB to serial
> >>> converters (with level shift for RS232).
> >>>
> >>> While looking into that, I came across a chip that combines this
> >>> functionality (except the level shift).
> >>>
> >>>
> >>> https://ftdichip.com/products/ft4232hq/
> >>>
> >>> https://www.aliexpress.com/item/1005001928940997.html
> >>>
> >>>
> >>> Searching through the XCS source I did not find the term "FT4232".
> >>>
> >>> So my question is if this chipset will work on the android platform
> >>> with
> >>> USB OTG or if it can be made to work with not too much effort.
> >>>
> >>> IMHO, combined with simple MAX232 level shifters this would be a very
> >>> nice setup to connect up to 4 serial devices to XCSoar.
> >>>
> >>>
> >>> I'm also open to other suggestions. =)
> >>>
> >>>
> >>> Cheers !
> >>>
> >>> Henrik
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Xcsoar-devel mailing list
> >>> Xcs...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Xcsoar-devel mailing list
> >> Xcs...@li...
> >> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
> >
>
>

Re: [Xcsoar-devel] OTG Driver for FT4232 (USB to 4 port UART)

[Henrik B. <hen...@gm...>]

Hello Helmut,

thanks for you feedback.

Am 11.07.22 um 11:28 schrieb Helmut J. Rohs:
> I ended up trying multiple USB-hubs with varying success. Most
> importantly the issue was to get power supplied to the Android at the
> same time as OTG connectivity. An USB hub in principle does the job to
> connect multiple devices in parallel very well. USB/RS232 converter
> and the proper level shifter are available in any desired form. So I
> would not look for a specific USB/RS232 adapter that comprises
> multiple ports, rather than looking for the USB hub with just the
> appropriate number of ports. All the hubs I tried worked perfectly in
> terms of accomplishing the 1 to many (device) connectivity for the
> XCS/Android display.
>

> My use case is as follows:
>
> XCS/Androis - connects to:
> -> USB audio card
> -> USB I-panel outlet (maybe a phone to charge, or a memory stick)
> -> NMEA srteam from variometer
> -> ACD/radio (to set frequencies)
> <- and finally a DC/DC converter providing 5V

I get your point. However for me right now I have less use for
additional USB-Connectivity and need three or four RS232 interfaces, so
i just think the solution with the 4-port FT4232 will provide for a
cleaner setup in my case. If needed later on a USB-Hub could be added
"on top".

(The USB-audio sounds interesting, since I discarded some possible E-Ink
Devices because they did not provide their own speaker audio)


> This hub i.e.
> https://www.amazon.de/-/en/gp/product/B07Z4RHJ2D/ref=ppx_od_dt_b_asin_image_s01?ie=UTF8&psc=1
> does fine for the first four items. You just allocate the next
> recognized RS232 dongle in XCS and configure it with the desired rates
> and protocols.
>
> My observation on drawing power from the USB-C connector to the
> Android have been not so successful. It work always as long as the
> Android is switched off. Then the Android accepts power. For the
> moment it uses the OTG connectivity the power drawing is refused. And
> on top of this, just not always. Once the Android successful draws
> power the adding of OTG connectivity does not interrupt the power
> drawing.
>
This sounds like PD-Behaviour without a dedicated chip switching to the
desired state. I think the PD-OTG-Power-Adapter must have such a chip
built in.
> Up to now I dont have a clue why that. It could be the specific design
> of the Android ebook reader, it could be the PD protocol design, which
> I dont know.
>
> I will try your suggested PD adapter and cascade it with my hub. You
> might try to solve your multi port issue with a hub?!
>
For me i works perfectly. Independent of which part of the setup is
switched on first.

(Adding/Removing power while connected, will require a Device-reconnect
in XCSoar, since the power to the FTDI is interrupted for a short moment
when making the change)


> We should definitely move this discussion to xcsoar on github. I think
> this going digital in cockpits is of wide interest for many of us.
>
Ok. Good idea! I opened a ticket on github:
https://github.com/XCSoar/XCSoar/issues/968


Cheers Henrik


> cheers
>
> Helmut
>
> Am 07.07.22 um 16:06 schrieb Henrik Bieler:
>> Hello!
>>
>> After I announced my plan to make use of FT4232 to interface multiple
>> RS232 Streams to XCSoar, I received requests from several people to let
>> them know if I have success with this setup.
>> I will give you you all a short summary on the status.
>>
>> Obviously the goal is to have power supplied TO the phone while at the
>> same time the phone is acting as USB-(OTG-)-Host.
>> This not trivial, but my research revealed that this should be possible:
>>
>> - on Micro-USB with a 124K pull down resistor on the ID line and **IF**
>> the standard is correctly implemented by the phone firmware.
>>   (I did not follow through on this method since I think MicroUSB will
>> be obsolete soon)
>>
>> -on USB-C this seems ONLY be possible by making use of the
>> PowerDelivery-Protocol (PD), which can be used to switch to the desired
>> state. (Phone charging but acting as host)
>>
>> I found an USB-C adaptor which promises to do exactly that.
>> https://de.aliexpress.com/item/1005003887696758.html
>>
>> And indeed this works (confirmed on a Pixel4a) ! =)
>> However the phone needs to be able to "talk" PD. Just an
>> USB-C-Receptacle is not sufficient.
>>
>> I am able to receive a Flarm-compatible NMEA Stream into XCSoar while
>> charging the phone. =)
>> (Caution: If you want to connect a real RS232 device you also need
>> MAX(3)232 level shifters, or you can fry the FTDI)
>>
>> However there is some work to be done on the XCSoar side:
>>
>> On XCSoar on Linux the 4 Ports of the FTDI4232 are natively recognized
>> as ttyUSB(0-3) and so all work as expected.
>> However on Android the FTDI4232 shows up as only one device instead of
>> four. It works, but only on the first channel.
>>
>> I am not a programmer. So could anyone help implementing the three
>> remaining channels in XCSoar? Or at least point me to where to get
>> started and maybe a general idea how to do it? I think this should not
>> be too difficult for anyone familiar with that part of the code.
>>
>> If this can be made to work (which I am positive that it will), this
>> will be a great new kind to interface all of our RS232 Streams in the
>> Cockpit to XCSoar. (Flarm, Radio, ADS-B, Sensor-Board, SoftRF, ......)
>>
>> Hoping for your help!
>> Henrik
>>
>>
>>
>>
>> Am 21.06.22 um 10:58 schrieb Henrik Bieler:
>>> Hey everyone,
>>>
>>>
>>> my cockpit will need a major overhaul the next winter and i am
>>> considering to replace my IOIO-OTG setup, which I am using to
>>> connect to
>>> FLARM, LXNano, and KRT2 with something more generic, since the
>>> IOIO-Boards seem to be less available and getting no recent
>>> development.
>>>
>>> I was considering to connect a USB-OTG Hub and 3 USB to serial
>>> converters (with level shift for RS232).
>>>
>>> While looking into that, I came across a chip that combines this
>>> functionality (except the level shift).
>>>
>>>
>>> https://ftdichip.com/products/ft4232hq/
>>>
>>> https://www.aliexpress.com/item/1005001928940997.html
>>>
>>>
>>> Searching through the XCS source I did not find the term "FT4232".
>>>
>>> So my question is if this chipset will work on the android platform
>>> with
>>> USB OTG or if it can be made to work with not too much effort.
>>>
>>> IMHO, combined with simple MAX232 level shifters this would be a very
>>> nice setup to connect up to 4 serial devices to XCSoar.
>>>
>>>
>>> I'm also open to other suggestions. =)
>>>
>>>
>>> Cheers !
>>>
>>> Henrik
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xcsoar-devel mailing list
>>> Xcs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>>
>>
>>
>>
>> _______________________________________________
>> Xcsoar-devel mailing list
>> Xcs...@li...
>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>

Re: [Xcsoar-devel] OTG Driver for FT4232 (USB to 4 port UART)

[Helmut J. R. <hel...@we...>]

XCNav is going in the right direction.

My requirements to this are 110mm x 170mm; max. 150mA@12V; reflective 
display with backlight option (MIP); all connectors on the rear side.

I am all in, yes.

XCNav needs junt another iteration to be a real good solution. It's show 
stoper to have connectors to the side for panel mounted avionics. Also 
the behind the panel portion could be way smaller (and option for 
connectors on the top side). Power foot print just should be less the 
15mA@12V.

Technologies is all out there, I know.


Am 11.07.22 um 11:38 schrieb Richard Frawley:
> Look at XCNav.
>
> Connectivity built in.
>
> Full android, support
>
>
>
>> On 11 Jul 2022, at 19:29, Helmut J. Rohs <hel...@we...> wrote:
>>
>> Hey Henrik,
>>
>> thanks for posting your story, I am on the same trails to find a solution for our two seater cockpit. Started my story here: https://github.com/XCSoar/XCSoar/discussions/844
>>
>> The title of the discussion might not lead straight to your topic, but it tries essentially to solve the same challenge: How to connect XCS/Android to multiple devices.
>>
>> I ended up trying multiple USB-hubs with varying success. Most importantly the issue was to get power supplied to the Android at the same time as OTG connectivity. An USB hub in principle does the job to connect multiple devices in parallel very well. USB/RS232 converter and the proper level shifter are available in any desired form. So I would not look for a specific USB/RS232 adapter that comprises multiple ports, rather than looking for the USB hub with just the appropriate number of ports. All the hubs I tried worked perfectly in terms of accomplishing the 1 to many (device) connectivity for the XCS/Android display.
>>
>> My use case is as follows:
>>
>> XCS/Androis - connects to:
>> -> USB audio card
>> -> USB I-panel outlet (maybe a phone to charge, or a memory stick)
>> -> NMEA srteam from variometer
>> -> ACD/radio (to set frequencies)
>> <- and finally a DC/DC converter providing 5V
>>
>> This hub i.e. https://www.amazon.de/-/en/gp/product/B07Z4RHJ2D/ref=ppx_od_dt_b_asin_image_s01?ie=UTF8&psc=1 does fine for the first four items. You just allocate the next recognized RS232 dongle in XCS and configure it with the desired rates and protocols.
>>
>> My observation on drawing power from the USB-C connector to the Android have been not so successful. It work always as long as the Android is switched off. Then the Android accepts power. For the moment it uses the OTG connectivity the power drawing is refused. And on top of this, just not always. Once the Android successful draws power the adding of OTG connectivity does not interrupt the power drawing.
>>
>> Up to now I dont have a clue why that. It could be the specific design of the Android ebook reader, it could be the PD protocol design, which I dont know.
>>
>> I will try your suggested PD adapter and cascade it with my hub. You might try to solve your multi port issue with a hub?!
>>
>> We should definitely move this discussion to xcsoar on github. I think this going digital in cockpits is of wide interest for many of us.
>>
>> cheers
>>
>> Helmut
>>
>>> Am 07.07.22 um 16:06 schrieb Henrik Bieler:
>>> Hello!
>>>
>>> After I announced my plan to make use of FT4232 to interface multiple
>>> RS232 Streams to XCSoar, I received requests from several people to let
>>> them know if I have success with this setup.
>>> I will give you you all a short summary on the status.
>>>
>>> Obviously the goal is to have power supplied TO the phone while at the
>>> same time the phone is acting as USB-(OTG-)-Host.
>>> This not trivial, but my research revealed that this should be possible:
>>>
>>> - on Micro-USB with a 124K pull down resistor on the ID line and **IF**
>>> the standard is correctly implemented by the phone firmware.
>>>    (I did not follow through on this method since I think MicroUSB will
>>> be obsolete soon)
>>>
>>> -on USB-C this seems ONLY be possible by making use of the
>>> PowerDelivery-Protocol (PD), which can be used to switch to the desired
>>> state. (Phone charging but acting as host)
>>>
>>> I found an USB-C adaptor which promises to do exactly that.
>>> https://de.aliexpress.com/item/1005003887696758.html
>>>
>>> And indeed this works (confirmed on a Pixel4a) ! =)
>>> However the phone needs to be able to "talk" PD. Just an
>>> USB-C-Receptacle is not sufficient.
>>>
>>> I am able to receive a Flarm-compatible NMEA Stream into XCSoar while
>>> charging the phone. =)
>>> (Caution: If you want to connect a real RS232 device you also need
>>> MAX(3)232 level shifters, or you can fry the FTDI)
>>>
>>> However there is some work to be done on the XCSoar side:
>>>
>>> On XCSoar on Linux the 4 Ports of the FTDI4232 are natively recognized
>>> as ttyUSB(0-3) and so all work as expected.
>>> However on Android the FTDI4232 shows up as only one device instead of
>>> four. It works, but only on the first channel.
>>>
>>> I am not a programmer. So could anyone help implementing the three
>>> remaining channels in XCSoar? Or at least point me to where to get
>>> started and maybe a general idea how to do it? I think this should not
>>> be too difficult for anyone familiar with that part of the code.
>>>
>>> If this can be made to work (which I am positive that it will), this
>>> will be a great new kind to interface all of our RS232 Streams in the
>>> Cockpit to XCSoar. (Flarm, Radio, ADS-B, Sensor-Board, SoftRF, ......)
>>>
>>> Hoping for your help!
>>> Henrik
>>>
>>>
>>>
>>>
>>>> Am 21.06.22 um 10:58 schrieb Henrik Bieler:
>>>> Hey everyone,
>>>>
>>>>
>>>> my cockpit will need a major overhaul the next winter and i am
>>>> considering to replace my IOIO-OTG setup, which I am using to connect to
>>>> FLARM, LXNano, and KRT2 with something more generic, since the
>>>> IOIO-Boards seem to be less available and getting no recent development.
>>>>
>>>> I was considering to connect a USB-OTG Hub and 3 USB to serial
>>>> converters (with level shift for RS232).
>>>>
>>>> While looking into that, I came across a chip that combines this
>>>> functionality (except the level shift).
>>>>
>>>>
>>>> https://ftdichip.com/products/ft4232hq/
>>>>
>>>> https://www.aliexpress.com/item/1005001928940997.html
>>>>
>>>>
>>>> Searching through the XCS source I did not find the term "FT4232".
>>>>
>>>> So my question is if this chipset will work on the android platform with
>>>> USB OTG or if it can be made to work with not too much effort.
>>>>
>>>> IMHO, combined with simple MAX232 level shifters this would be a very
>>>> nice setup to connect up to 4 serial devices to XCSoar.
>>>>
>>>>
>>>> I'm also open to other suggestions. =)
>>>>
>>>>
>>>> Cheers !
>>>>
>>>> Henrik
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xcsoar-devel mailing list
>>>> Xcs...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Xcsoar-devel mailing list
>>> Xcs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>> -- 
>> Helmut Rohs
>> t: +49 761 887 990 24
>> m: +49 151 250 505 44
>>
>>
>>
>> _______________________________________________
>> Xcsoar-devel mailing list
>> Xcs...@li...
>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

-- 
Helmut Rohs
t: +49 761 887 990 24
m: +49 151 250 505 44

Re: [Xcsoar-devel] OTG Driver for FT4232 (USB to 4 port UART)

[Helmut J. R. <hel...@we...>]

Hey Henrik,

thanks for posting your story, I am on the same trails to find a 
solution for our two seater cockpit. Started my story here: 
https://github.com/XCSoar/XCSoar/discussions/844

The title of the discussion might not lead straight to your topic, but 
it tries essentially to solve the same challenge: How to connect 
XCS/Android to multiple devices.

I ended up trying multiple USB-hubs with varying success. Most 
importantly the issue was to get power supplied to the Android at the 
same time as OTG connectivity. An USB hub in principle does the job to 
connect multiple devices in parallel very well. USB/RS232 converter and 
the proper level shifter are available in any desired form. So I would 
not look for a specific USB/RS232 adapter that comprises multiple ports, 
rather than looking for the USB hub with just the appropriate number of 
ports. All the hubs I tried worked perfectly in terms of accomplishing 
the 1 to many (device) connectivity for the XCS/Android display.

My use case is as follows:

XCS/Androis - connects to:
-> USB audio card
-> USB I-panel outlet (maybe a phone to charge, or a memory stick)
-> NMEA srteam from variometer
-> ACD/radio (to set frequencies)
<- and finally a DC/DC converter providing 5V

This hub i.e. 
https://www.amazon.de/-/en/gp/product/B07Z4RHJ2D/ref=ppx_od_dt_b_asin_image_s01?ie=UTF8&psc=1 
does fine for the first four items. You just allocate the next 
recognized RS232 dongle in XCS and configure it with the desired rates 
and protocols.

My observation on drawing power from the USB-C connector to the Android 
have been not so successful. It work always as long as the Android is 
switched off. Then the Android accepts power. For the moment it uses the 
OTG connectivity the power drawing is refused. And on top of this, just 
not always. Once the Android successful draws power the adding of OTG 
connectivity does not interrupt the power drawing.

Up to now I dont have a clue why that. It could be the specific design 
of the Android ebook reader, it could be the PD protocol design, which I 
dont know.

I will try your suggested PD adapter and cascade it with my hub. You 
might try to solve your multi port issue with a hub?!

We should definitely move this discussion to xcsoar on github. I think 
this going digital in cockpits is of wide interest for many of us.

cheers

Helmut

Am 07.07.22 um 16:06 schrieb Henrik Bieler:
> Hello!
>
> After I announced my plan to make use of FT4232 to interface multiple
> RS232 Streams to XCSoar, I received requests from several people to let
> them know if I have success with this setup.
> I will give you you all a short summary on the status.
>
> Obviously the goal is to have power supplied TO the phone while at the
> same time the phone is acting as USB-(OTG-)-Host.
> This not trivial, but my research revealed that this should be possible:
>
> - on Micro-USB with a 124K pull down resistor on the ID line and **IF**
> the standard is correctly implemented by the phone firmware.
>   (I did not follow through on this method since I think MicroUSB will
> be obsolete soon)
>
> -on USB-C this seems ONLY be possible by making use of the
> PowerDelivery-Protocol (PD), which can be used to switch to the desired
> state. (Phone charging but acting as host)
>
> I found an USB-C adaptor which promises to do exactly that.
> https://de.aliexpress.com/item/1005003887696758.html
>
> And indeed this works (confirmed on a Pixel4a) ! =)
> However the phone needs to be able to "talk" PD. Just an
> USB-C-Receptacle is not sufficient.
>
> I am able to receive a Flarm-compatible NMEA Stream into XCSoar while
> charging the phone. =)
> (Caution: If you want to connect a real RS232 device you also need
> MAX(3)232 level shifters, or you can fry the FTDI)
>
> However there is some work to be done on the XCSoar side:
>
> On XCSoar on Linux the 4 Ports of the FTDI4232 are natively recognized
> as ttyUSB(0-3) and so all work as expected.
> However on Android the FTDI4232 shows up as only one device instead of
> four. It works, but only on the first channel.
>
> I am not a programmer. So could anyone help implementing the three
> remaining channels in XCSoar? Or at least point me to where to get
> started and maybe a general idea how to do it? I think this should not
> be too difficult for anyone familiar with that part of the code.
>
> If this can be made to work (which I am positive that it will), this
> will be a great new kind to interface all of our RS232 Streams in the
> Cockpit to XCSoar. (Flarm, Radio, ADS-B, Sensor-Board, SoftRF, ......)
>
> Hoping for your help!
> Henrik
>
>
>
>
> Am 21.06.22 um 10:58 schrieb Henrik Bieler:
>> Hey everyone,
>>
>>
>> my cockpit will need a major overhaul the next winter and i am
>> considering to replace my IOIO-OTG setup, which I am using to connect to
>> FLARM, LXNano, and KRT2 with something more generic, since the
>> IOIO-Boards seem to be less available and getting no recent development.
>>
>> I was considering to connect a USB-OTG Hub and 3 USB to serial
>> converters (with level shift for RS232).
>>
>> While looking into that, I came across a chip that combines this
>> functionality (except the level shift).
>>
>>
>> https://ftdichip.com/products/ft4232hq/
>>
>> https://www.aliexpress.com/item/1005001928940997.html
>>
>>
>> Searching through the XCS source I did not find the term "FT4232".
>>
>> So my question is if this chipset will work on the android platform with
>> USB OTG or if it can be made to work with not too much effort.
>>
>> IMHO, combined with simple MAX232 level shifters this would be a very
>> nice setup to connect up to 4 serial devices to XCSoar.
>>
>>
>> I'm also open to other suggestions. =)
>>
>>
>> Cheers !
>>
>> Henrik
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xcsoar-devel mailing list
>> Xcs...@li...
>> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>
>
>
>
> _______________________________________________
> Xcsoar-devel mailing list
> Xcs...@li...
> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

-- 
Helmut Rohs
t: +49 761 887 990 24
m: +49 151 250 505 44

Re: [Xcsoar-devel] OTG Driver for FT4232 (USB to 4 port UART)

[Henrik B. <hen...@gm...>]

Hello!

After I announced my plan to make use of FT4232 to interface multiple
RS232 Streams to XCSoar, I received requests from several people to let
them know if I have success with this setup.
I will give you you all a short summary on the status.

Obviously the goal is to have power supplied TO the phone while at the
same time the phone is acting as USB-(OTG-)-Host.
This not trivial, but my research revealed that this should be possible:

- on Micro-USB with a 124K pull down resistor on the ID line and **IF**
the standard is correctly implemented by the phone firmware.
   (I did not follow through on this method since I think MicroUSB will
be obsolete soon)

-on USB-C this seems ONLY be possible by making use of the
PowerDelivery-Protocol (PD), which can be used to switch to the desired
state. (Phone charging but acting as host)

I found an USB-C adaptor which promises to do exactly that.
https://de.aliexpress.com/item/1005003887696758.html

And indeed this works (confirmed on a Pixel4a) ! =)
However the phone needs to be able to "talk" PD. Just an
USB-C-Receptacle is not sufficient.

I am able to receive a Flarm-compatible NMEA Stream into XCSoar while
charging the phone. =)
(Caution: If you want to connect a real RS232 device you also need
MAX(3)232 level shifters, or you can fry the FTDI)

However there is some work to be done on the XCSoar side:

On XCSoar on Linux the 4 Ports of the FTDI4232 are natively recognized
as ttyUSB(0-3) and so all work as expected.
However on Android the FTDI4232 shows up as only one device instead of
four. It works, but only on the first channel.

I am not a programmer. So could anyone help implementing the three
remaining channels in XCSoar? Or at least point me to where to get
started and maybe a general idea how to do it? I think this should not
be too difficult for anyone familiar with that part of the code.

If this can be made to work (which I am positive that it will), this
will be a great new kind to interface all of our RS232 Streams in the
Cockpit to XCSoar. (Flarm, Radio, ADS-B, Sensor-Board, SoftRF, ......)

Hoping for your help!
Henrik




Am 21.06.22 um 10:58 schrieb Henrik Bieler:
> Hey everyone,
>
>
> my cockpit will need a major overhaul the next winter and i am
> considering to replace my IOIO-OTG setup, which I am using to connect to
> FLARM, LXNano, and KRT2 with something more generic, since the
> IOIO-Boards seem to be less available and getting no recent development.
>
> I was considering to connect a USB-OTG Hub and 3 USB to serial
> converters (with level shift for RS232).
>
> While looking into that, I came across a chip that combines this
> functionality (except the level shift).
>
>
> https://ftdichip.com/products/ft4232hq/
>
> https://www.aliexpress.com/item/1005001928940997.html
>
>
> Searching through the XCS source I did not find the term "FT4232".
>
> So my question is if this chipset will work on the android platform with
> USB OTG or if it can be made to work with not too much effort.
>
> IMHO, combined with simple MAX232 level shifters this would be a very
> nice setup to connect up to 4 serial devices to XCSoar.
>
>
> I'm also open to other suggestions. =)
>
>
> Cheers !
>
> Henrik
>
>
>
>
>
> _______________________________________________
> Xcsoar-devel mailing list
> Xcs...@li...
> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[Xcsoar-devel] OTG Driver for FT4232 (USB to 4 port UART)

[Henrik B. <hen...@gm...>]

Hey everyone,


my cockpit will need a major overhaul the next winter and i am
considering to replace my IOIO-OTG setup, which I am using to connect to
FLARM, LXNano, and KRT2 with something more generic, since the
IOIO-Boards seem to be less available and getting no recent development.

I was considering to connect a USB-OTG Hub and 3 USB to serial
converters (with level shift for RS232).

While looking into that, I came across a chip that combines this
functionality (except the level shift).


https://ftdichip.com/products/ft4232hq/

https://www.aliexpress.com/item/1005001928940997.html


Searching through the XCS source I did not find the term "FT4232".

So my question is if this chipset will work on the android platform with
USB OTG or if it can be made to work with not too much effort.

IMHO, combined with simple MAX232 level shifters this would be a very
nice setup to connect up to 4 serial devices to XCSoar.


I'm also open to other suggestions. =)


Cheers !

Henrik

Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar

[Ludovic L. <lu...@la...>]

Hi

I started looking at that a few years ago when I developed some features
for Tophat Soaring (a XCSoar fork).
The problem is that the .cpux format (binary format), is not public and not
documented.
There have been attempts at reverse engineering it, but at the time, I
don't think there was any fully acceptable long term solution on this.

For this to work, we would need:
- A documentation on the format
- A library (C / C++) to parse it
- Implement it in XCSoar

Regards
Ludovic

---
Ludovic Launer
lu...@la...
<http://www.launer.fr>


On Wed, 26 May 2021 at 08:22, Henrik Bieler <hen...@gm...> wrote:

> Hello devs,
>
> The database of outlanding sites streckenflug.at already has is very
> impressive.
>
> It has extensive coverage of the Alps, BlackForest and Pfälzerwald,
> already some in South Africa and North America the quality of the data
> is good and it is open for new entries.
>
> Check it out at https://landewiesen.streckenflug.at
>
> IMO it coud become THE central outlanding database for every glider pilot.
>
>
> I proposed to Christian to provide the data in the "WaypoitDetails.txt
> and picture folder"-Format XCSoar uses right now. But they want a more
> compact solution.
>
> >Vereinfacht, wir bevorzugen Formate die möglichst eine Aktualität auf den
> Endgeräten fördern. Genau dagegen
> spricht die derzeitigen XCS Implementierung.
>
> >Wir wollen ein dokumentiertes Format einführen, dafür braucht es aber den
> Willen von XCS.
>
>
> I think it would be a large benefit for both projects if the data could
> be made available on XCSoar.
> I would be willing to help with that, as far as I can, but I lack the
> programming skills, and the knowledge of the codebase to do this on my own.
>
> Cheers Henrik
>
>
> Am 25.05.21 um 23:51 schrieb Christian Hynek:
> > Hello Max,
> >
> > Thank you for your feedback. As you described, we want a file format
> that compresses the data and images and is decompressed by the application.
> >
> > Last week and today we had again requests from XCS users, so we ask
> again if we would like to implement something together!
> >
> > Best regards
> > Christian
> >
> >
> -----------------------------------------------------------------------------------------------------
> > streckenflug.at - Shop
> > Christian Hynek
> > ch...@st...<mailto:ch...@st...>
> >
> > News      http://www.streckenflug.at<http://www.streckenflug.at/>
> > Shop        http://shop.streckenflug.at<http://shop.streckenflug.at/>
> > sis-at       http://sis-at.streckenflug.at<
> http://sis-at.streckenflug.at/>
> > Landout   http://landout.streckenflug.at<http://landout.streckenflug.at/
> >
> >
> > Hauptstrasse 69
> > 2723 Muthmannsdorf
> > Austria
> >
> -----------------------------------------------------------------------------------------------------
> >
> > Von: Max Kellermann <ma...@bl...>
> > Gesendet: Montag, 3. Mai 2021 13:43
> > An: Christian Hynek <ch...@st...>
> > Cc: xcs...@li...
> > Betreff: Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar
> >
> >
> > On 2021/05/03 09:53, Christian Hynek <ch...@st...> wrote:
> >> mein Name ist Christian (Hynek) und ich betreibe die streckenflug.at
> > und seit diesem Jahr ist das Landewiesen Projekt wieder aktiv.
> >
> > (I'm German, but I'll reply in English to avoid excluding anybody from
> > the discussion.)
> >
> >> Two weeks ago we have also activated the download for cupx, so the
> > data + pictures. Now there are also requests if we can provide the data
> > with pictures also for XCSoar.
> >> Of course we can do that, but it would have to be in a reasonable
> > bundled format. Apparently XCSoar does not support cupx.
> >
> > Support for CUPX was requested quite a few times over the years, but
> > CUPX is a proprietary and undocumented format.  That's why XCSoar
> > doesn't support it.
> >
> > Maybe there is documentation meanwhile, then we could add that.
> >
> >> The question is if you want to include the landout points in XCSoar
> > with us!?
> >
> > (I myself have quitted flying 5 years ago, but) I imagine that XCSoar
> > users would be very interested in this.
> >
> > What options do we have?  As long as CUPX is undocumented, we can't
> > use that.  What is your primary file format, what tools do you use to
> > maintain your data and generate the CUPX?
> >
> > XCSoar has a feature named "airfield details file" which allows
> > associating images or other files with waypoints.  Though I don't
> > think this feature is well-designed.  For what you're doing, the
> > waypoints and the images should be in one file, like CUPX does.  The
> > simplest idea would be to have a ZIP file containing the waypoint file
> > and one image file per waypoint (named after the waypoint?)
> >
> > Max
> >
> >
> > _______________________________________________
> > Xcsoar-devel mailing list
> > Xcs...@li...
> > https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>
>
>
> _______________________________________________
> Xcsoar-devel mailing list
> Xcs...@li...
> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>

Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar

[Henrik B. <hen...@gm...>]

Hello devs,

The database of outlanding sites streckenflug.at already has is very
impressive.

It has extensive coverage of the Alps, BlackForest and Pfälzerwald,
already some in South Africa and North America the quality of the data
is good and it is open for new entries.

Check it out at https://landewiesen.streckenflug.at

IMO it coud become THE central outlanding database for every glider pilot.


I proposed to Christian to provide the data in the "WaypoitDetails.txt
and picture folder"-Format XCSoar uses right now. But they want a more
compact solution.

>Vereinfacht, wir bevorzugen Formate die möglichst eine Aktualität auf den Endgeräten fördern. Genau dagegen
spricht die derzeitigen XCS Implementierung.

>Wir wollen ein dokumentiertes Format einführen, dafür braucht es aber den Willen von XCS.


I think it would be a large benefit for both projects if the data could
be made available on XCSoar.
I would be willing to help with that, as far as I can, but I lack the
programming skills, and the knowledge of the codebase to do this on my own.

Cheers Henrik


Am 25.05.21 um 23:51 schrieb Christian Hynek:
> Hello Max,
>
> Thank you for your feedback. As you described, we want a file format that compresses the data and images and is decompressed by the application.
>
> Last week and today we had again requests from XCS users, so we ask again if we would like to implement something together!
>
> Best regards
> Christian
>
> -----------------------------------------------------------------------------------------------------
> streckenflug.at - Shop
> Christian Hynek
> ch...@st...<mailto:ch...@st...>
>
> News      http://www.streckenflug.at<http://www.streckenflug.at/>
> Shop        http://shop.streckenflug.at<http://shop.streckenflug.at/>
> sis-at       http://sis-at.streckenflug.at<http://sis-at.streckenflug.at/>
> Landout   http://landout.streckenflug.at<http://landout.streckenflug.at/>
>
> Hauptstrasse 69
> 2723 Muthmannsdorf
> Austria
> -----------------------------------------------------------------------------------------------------
>
> Von: Max Kellermann <ma...@bl...>
> Gesendet: Montag, 3. Mai 2021 13:43
> An: Christian Hynek <ch...@st...>
> Cc: xcs...@li...
> Betreff: Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar
>
>
> On 2021/05/03 09:53, Christian Hynek <ch...@st...> wrote:
>> mein Name ist Christian (Hynek) und ich betreibe die streckenflug.at
> und seit diesem Jahr ist das Landewiesen Projekt wieder aktiv.
>
> (I'm German, but I'll reply in English to avoid excluding anybody from
> the discussion.)
>
>> Two weeks ago we have also activated the download for cupx, so the
> data + pictures. Now there are also requests if we can provide the data
> with pictures also for XCSoar.
>> Of course we can do that, but it would have to be in a reasonable
> bundled format. Apparently XCSoar does not support cupx.
>
> Support for CUPX was requested quite a few times over the years, but
> CUPX is a proprietary and undocumented format.  That's why XCSoar
> doesn't support it.
>
> Maybe there is documentation meanwhile, then we could add that.
>
>> The question is if you want to include the landout points in XCSoar
> with us!?
>
> (I myself have quitted flying 5 years ago, but) I imagine that XCSoar
> users would be very interested in this.
>
> What options do we have?  As long as CUPX is undocumented, we can't
> use that.  What is your primary file format, what tools do you use to
> maintain your data and generate the CUPX?
>
> XCSoar has a feature named "airfield details file" which allows
> associating images or other files with waypoints.  Though I don't
> think this feature is well-designed.  For what you're doing, the
> waypoints and the images should be in one file, like CUPX does.  The
> simplest idea would be to have a ZIP file containing the waypoint file
> and one image file per waypoint (named after the waypoint?)
>
> Max
>
>
> _______________________________________________
> Xcsoar-devel mailing list
> Xcs...@li...
> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar

[Christian H. <ch...@st...>]

Hello Max,

Thank you for your feedback. As you described, we want a file format that compresses the data and images and is decompressed by the application.

Last week and today we had again requests from XCS users, so we ask again if we would like to implement something together!

Best regards
Christian

-----------------------------------------------------------------------------------------------------
streckenflug.at - Shop
Christian Hynek
ch...@st...<mailto:ch...@st...>

News      http://www.streckenflug.at<http://www.streckenflug.at/>
Shop        http://shop.streckenflug.at<http://shop.streckenflug.at/>
sis-at       http://sis-at.streckenflug.at<http://sis-at.streckenflug.at/>
Landout   http://landout.streckenflug.at<http://landout.streckenflug.at/>

Hauptstrasse 69
2723 Muthmannsdorf
Austria
-----------------------------------------------------------------------------------------------------

Von: Max Kellermann <ma...@bl...>
Gesendet: Montag, 3. Mai 2021 13:43
An: Christian Hynek <ch...@st...>
Cc: xcs...@li...
Betreff: Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar


On 2021/05/03 09:53, Christian Hynek <ch...@st...> wrote:
> mein Name ist Christian (Hynek) und ich betreibe die streckenflug.at
und seit diesem Jahr ist das Landewiesen Projekt wieder aktiv.

(I'm German, but I'll reply in English to avoid excluding anybody from
the discussion.)

> Two weeks ago we have also activated the download for cupx, so the
data + pictures. Now there are also requests if we can provide the data
with pictures also for XCSoar.
>
> Of course we can do that, but it would have to be in a reasonable
bundled format. Apparently XCSoar does not support cupx.

Support for CUPX was requested quite a few times over the years, but
CUPX is a proprietary and undocumented format.  That's why XCSoar
doesn't support it.

Maybe there is documentation meanwhile, then we could add that.

> The question is if you want to include the landout points in XCSoar
with us!?

(I myself have quitted flying 5 years ago, but) I imagine that XCSoar
users would be very interested in this.

What options do we have?  As long as CUPX is undocumented, we can't
use that.  What is your primary file format, what tools do you use to
maintain your data and generate the CUPX?

XCSoar has a feature named "airfield details file" which allows
associating images or other files with waypoints.  Though I don't
think this feature is well-designed.  For what you're doing, the
waypoints and the images should be in one file, like CUPX does.  The
simplest idea would be to have a ZIP file containing the waypoint file
and one image file per waypoint (named after the waypoint?)

Max

[Xcsoar-devel] debugging on Windows

[Ronald N. <ron...@fr...>]

Hi,

can somebody help me getting a debugger installed and configured so I can analyze the result of "make TARGET=WIN64".
I'm trying to track down an issues which I expect to be in the Windows specific part of XCSoar.
I prefer gdb because this is what I know from Linux. And I don't want to clutter my Windows PC with unnecessary bloat.

I have installed MinGW with gdb. But when I run "c:\MinGW\bin\gdb.exe XCSoar.exe" it says
"C:\Users\ronald\Documents\dbg/XCSoar.exe": not in executable format: File format not recognized

This particular file is executable!

Any hints??

For the curious ones: this is what I'm hoping to pin down:
https://github.com/XCSoar/XCSoar/issues/602
https://github.com/XCSoar/XCSoar/issues/603

-- 
Viele Grüße,

Ronald Niederhagen

Re: [Xcsoar-devel] streckenflug.at landout cupx and XCSoar

[Max K. <ma...@du...>]

On 2021/05/03 09:53, Christian Hynek <ch...@st...> wrote:
> mein Name ist Christian (Hynek) und ich betreibe die streckenflug.at und seit diesem Jahr ist das Landewiesen Projekt wieder aktiv.

(I'm German, but I'll reply in English to avoid excluding anybody from
the discussion.)

> Two weeks ago we have also activated the download for cupx, so the data + pictures. Now there are also requests if we can provide the data with pictures also for XCSoar.
> 
> Of course we can do that, but it would have to be in a reasonable bundled format. Apparently XCSoar does not support cupx.

Support for CUPX was requested quite a few times over the years, but
CUPX is a proprietary and undocumented format.  That's why XCSoar
doesn't support it.

Maybe there is documentation meanwhile, then we could add that.

> The question is if you want to include the landout points in XCSoar with us!?

(I myself have quitted flying 5 years ago, but) I imagine that XCSoar
users would be very interested in this.

What options do we have?  As long as CUPX is undocumented, we can't
use that.  What is your primary file format, what tools do you use to
maintain your data and generate the CUPX?

XCSoar has a feature named "airfield details file" which allows
associating images or other files with waypoints.  Though I don't
think this feature is well-designed.  For what you're doing, the
waypoints and the images should be in one file, like CUPX does.  The
simplest idea would be to have a ZIP file containing the waypoint file
and one image file per waypoint (named after the waypoint?)

Max

[Xcsoar-devel] streckenflug.at landout cupx and XCSoar

[Christian H. <ch...@st...>]

Hallo,

mein Name ist Christian (Hynek) und ich betreibe die streckenflug.at und seit diesem Jahr ist das Landewiesen Projekt wieder aktiv.

https://landewiesen.streckenflug.at

Vor zwei Wochen haben wir auch den Download für cupx, also die Daten + Bilder aktiviert. Jetzt gibt es auch Anfragen ob wir die Daten mit Bildern auch für XCSoar zur Verfügung stellen können.

Das können wir natürlich machen, aber es müsste in einem vernünftig gebündelten Format sein. Scheinbar unterstützt XCSoar cupx nicht.

Die Frage ist, ob ihr mit uns die Landewiesen in XCSoar einbinden wollt!?

--------

Hello,

my name is Christian (Hynek) and I run streckenflug.at and since this year the landout project is active again.

https://landout.streckenflug.at

Two weeks ago we have also activated the download for cupx, so the data + pictures. Now there are also requests if we can provide the data with pictures also for XCSoar.

Of course we can do that, but it would have to be in a reasonable bundled format. Apparently XCSoar does not support cupx.

The question is if you want to include the landout points in XCSoar with us!?


Grüße | Regards
Christian

-----------------------------------------------------------------------------------------------------
streckenflug.at
Christian Hynek
ch...@st...<mailto:ch...@st...>

Segelflugnews       http://www.streckenflug.at<http://www.streckenflug.at/>
Shop f. Piloten        http://shop.streckenflug.at<http://shop.streckenflug.at/>
sis-at Österr.          http://sis-at.streckenflug.at<http://sis-at.streckenflug.at/>
Landewiesen          http://landewiesen.streckenflug.at<http://landewiesen.streckenflug.at/>

Hauptstrasse 69
2723 Muthmannsdorf
Österreich
-----------------------------------------------------------------------------------------------------

Re: [Xcsoar-devel] 7.4 doesn't work on Kobo Mini

[Giacomo C. <cop...@gm...>]

Hello,
you try to install an old version on XCSoar.
But not removing the sd card, is better to operate on Kobo with usb
connection..
So, only reset the Kobo to factory. On web you can find the hard reset
procedure. After Kobo is a normal E-book reading, so try the touch.
After you can try to install an old version of Xc.

bye bye

Il giorno mar 13 apr 2021 alle ore 10:24 Dieter Schmieg <
die...@we...> ha scritto:

> Hi all,
>
> I use XCSoar in gliding since many years on different systems and thanks,
> it is working well - I like it!
>
> Now I tried to install XCSoar 7.4 on my Kobo Mini but with no success!
> After copying the 7.4 Kobo Installer to the .kobo directory and rebooting
> the system, I had no more touch screen functionality. Switching off the
> system is the only option after upgrading the Kobo Mini to XCSoar 7.4.
>
> I think after opening my Kobo, I have to take out the SD card and put it
> into my PC for downgrading to XCSoar 6.8.17. Do you think this is a
> possible way to proceed or are there other options?
>
> Thanks in advance
>
> Best regards
> Dieter Schmieg
>
>
>
> _______________________________________________
> Xcsoar-devel mailing list
> Xcs...@li...
> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>

[Xcsoar-devel] 7.4 doesn't work on Kobo Mini

[Dieter S. <die...@we...>]

Hi all,

I use XCSoar in gliding since many years on different systems and thanks, it is working well - I like it!

Now I tried to install XCSoar 7.4 on my Kobo Mini but with no success! After copying the 7.4 Kobo Installer to the .kobo directory and rebooting the system, I had no more touch screen functionality. Switching off the system is the only option after upgrading the Kobo Mini to XCSoar 7.4.

I think after opening my Kobo, I have to take out the SD card and put it
into my PC for downgrading to XCSoar 6.8.17. Do you think this is a
possible way to proceed or are there other options?

Thanks in advance

Best regards
Dieter Schmieg

[Xcsoar-devel] XcSoar on My paramotor

[Giacomo C. <cop...@gm...>]

Hello, i'm Giacomo from Italy, sorry for my English .
So i used XcSoar for long time on my paraglide, and i would like to use it
on my paramotor.
I made a Hardware with an Arduino for take some information from Engine,
like temperature of Exhaust and Spark, fuel sensor and a barometric sensor.
With Bluetooth i send the pressure to my telephone with XcSoar and i can
see the vario works.
I would like to add 3 windows (info box) on XcSoar for read the 2
temperatures and fuel level, but i don't know how to do that. Can somebody
help me please?
With this info box on XcSoar and my hardware i think a lot of para-motors
user can have a complete system on it. So i think is very interesting.
Thanks

best regards
Giacomo Candeo

[Xcsoar-devel] Patch to Allow Positioning of ThermalAssistant

[Adam W. <ad...@ad...>]

Hi All,

Patch attached, have adjusted the code to allow the selection of a position
to display the ThermalAssistant in settings. Allows bottom left or right,
with the option to avoid infoboxes by positioning over the map rather than
the infoboxes.

If this isn't a suitable method for submitting, is anyone willing to guide
me through uploading to Github, or point me at some info on how to do this?

Thanks

Adam

[Xcsoar-devel] paramotor

[Giacomo C. <cop...@gm...>]

Hello,
i'm Giacomo from Italy.
i used XcSoar in paraglide and thanks, is it works very well.
Now i'm approaching to paramotor and i do a little hardware project with
arduino and some sensor useful for have some information about engine and
fuel status.
I talk with my paramotor colleague and they say, with this hw, XcSoar will
be a complete useful system for paramotor too.
So i only need a 3 windows with 2 temperatures and one percentage of fuel.
is it possible?

thanks, sorry for my English.
bye bye

[Xcsoar-devel] 6.8.12 in Play Store

[Ronald N. <ron...@fr...>]

You probably noticed updates to 6.8.12 and 7.0-preview14 were pushed out
via Google Play Store.
But I see nothing on the XCSoar Download page
https://www.xcsoar.org/download/

What happened??

Cheers,
Ronald

Re: [Xcsoar-devel] Hungarian Airspace changes

[Wolfram Z. <rue...@wo...>]

Dear Attila,

thank you for your initiative. In means of providing data I suggest you to
contact people providing airspace data in means of a primary focus. Why not
contact the people from soaringweb.org? http://soaringweb.org/Airspace/HU
Airspace data may be provided in several file formats. I suggest the
OpenAir textfile format fits best. For Airfield data .cup files might be
the right choice. The .xcm file format is carrying the base map data
primarily.

Thank you,
Wolfram

PS.: openflightmaps.org may be another contact to start with.

Am Fr., 14. Feb. 2020 um 19:53 Uhr schrieb LÉVAI Attila <qw...@gm...>:

> Dear XCSoar Dev Team!
>
> I use the app for my flights, but recently Hungary has changed the airspace
> structure based on an optimized TMA and therefore most of the information
> provided in the HUN_HighRes.xcm file is outdated.
>
> I work as a Publication / Static Data Operation specialist in
> HungaroControl (Hungarian ANSP) and would like to support the development
> of the app with providing the updated airspace structure of Hungary coming
> into effect on the 30th of January.
>
> If you could tell me what format is the easiest way to process all the new
> TMA and other Glider Areas, let me know and I could prepare an up-to-date
> version of our FIR from the official database what is committed in the
> European Aeronautical Database.
>
> I also have all the airfields listed in the AIP and known by our NSA, if
> you could integrate those informations as well.
>
> Let me know.
>
> Kind regards,
> Attila
>
> _______________________________________________
> Xcsoar-devel mailing list
> Xcs...@li...
> https://lists.sourceforge.net/lists/listinfo/xcsoar-devel
>


-- 
Be careful when you follow the masses,
sometimes the m is silent.
Make the world Greta again.

Wolfram Zirngibl
rue...@wo...
+49 176 45867923

[Xcsoar-devel] Hungarian Airspace changes

[LÉVAI A. <qw...@gm...>]

Dear XCSoar Dev Team!

I use the app for my flights, but recently Hungary has changed the airspace
structure based on an optimized TMA and therefore most of the information
provided in the HUN_HighRes.xcm file is outdated.

I work as a Publication / Static Data Operation specialist in
HungaroControl (Hungarian ANSP) and would like to support the development
of the app with providing the updated airspace structure of Hungary coming
into effect on the 30th of January.

If you could tell me what format is the easiest way to process all the new
TMA and other Glider Areas, let me know and I could prepare an up-to-date
version of our FIR from the official database what is committed in the
European Aeronautical Database.

I also have all the airfields listed in the AIP and known by our NSA, if
you could integrate those informations as well.

Let me know.

Kind regards,
Attila

[Xcsoar-devel] patch on 7.0_preview14

[Ronald N. <ron...@fr...>]

Hi,

I'm addressing an issue which I have described here:
https://forum.xcsoar.org/viewtopic.php?f=30&t=3609

I've changed the limit of the aspect ration of the InfoBoxs so that the
rows of InfoBoxes don't use up more hight than needed. It kicks in if
the aspect ration of the screen gets too tall and narrow.
I don't know if this has the potential to break some "exotic" InfoBoxes.
The ones I know (which I had tested) seem to work OK.
It's the
	static constexpr double CONTROLHEIGHTRATIO = 9.0;
in InfoBoxes/InfoBoxLayout.cpp
It was 7.4; Is this a magic number??? 9.0 seem alright to me.

The second item I've changed: I added 2 screen layouts with 10 boxes:
	"10 Bottom or Right"
	"10 Top or Left"

The changes are in the attached patch file as suggested in the
developers manual.

Let me know if I can help in any way.

-- 
Cheers,
Ronald

[Xcsoar-devel] New toys in the design pipeline

[Helmut R. <hel...@gm...>]

Hey,

I am about to design a new bugwiper winch. It'll be "IOT" accessible.
Any preference in protocol scheme, or physical connection media for a
XC connectivity? 
I could envision BT, WIFI, RS232 (TTL), any other serial standard, USB?
What are design arguments/targets? 

A potential feature set will be:
 - Simple status read back -- ready/operating/error, version, etc.
 - Command a bug wiper run right/left wing. (Avoiding any other
cabeling and front panel space).
 - Enter calibration mode.
 - Display/modify configuration data (wingspan, limits, thresholds,
current sense read factor, etc.
 - Firmware update.

Could be imagined as a new custom NMEA tag, but also anything else.
What is the most promising path?

your feedback is welcome!

Thanks,

Helmut

Re: [Xcsoar-devel] XCSoar web server going down

[Philipp N. <ph...@ni...>]

Hello Max,


Folken and I are working on it.
We have a new host and the next step is doing the actual move.

I'll keep in contact with Folken and I'm ready to help in anyway necessary.

DNS updates:
Usually those don’t take a week anymore 😉
In my experience in most cases those are done within a few hours. (worldwide)

Regards
Philipp

-----Original Message-----
From: Max Kellermann <ma...@du...> 
Sent: Friday, 26 April 2019 10:21
To: xcs...@li...
Subject: Re: [Xcsoar-devel] XCSoar web server going down

On 2019/04/18 10:09, Max Kellermann <ma...@du...> wrote:
> On 2019/04/10 15:08, Max Kellermann <ma...@du...> wrote:
> > Since I don't have any time to manage a new one, please somebody 
> > take care for obtainbing a new hosting service for the website (and 
> > the forum).
> 
> If nobody steps up, the XCSoar website will be down soon, and all data 
> will be lost (including the forum posts etc.)

The problem must be solved this weekend.  The server will be gone on monday.  It's already too late for a smooth transition - the remaining time is not enough for DNS updates.  A downtime of a week or so cannot be avoided anymore.  But data loss can be avoided.

Btw. I've received quite a few emails - but that always requires me to manage the move.

And as I already wrote, I don't have any time to manage this (writing those emails is already taking too much of my time).  Getting a new server is only a minor part of the solution.  The real problem is getting the move done.  This isn't a hardware problem; this is a management problem.


_______________________________________________
Xcsoar-devel mailing list
Xcs...@li...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel