Messages

1

Technical Support / Re: Dead Rosetta - SD card slot has come adrift

« on: April 15, 2024, 03:09:47 pm »

Follow-up For Information

I asked Graham to send me the old board so I could examine it - never having come across this fault before. I have it sitting here in front of me as I type - thanks Graham.

The following is simply a statement of what I found and should not be taken as implying any negligence or inappropriate action by Graham - simply a cautionary tale for us all. It could easily have happened by the projecting end of the microSD card catching on something at any time when the unit was being fitted or removed from the plane, or from any bag it might have been carried in.

You should be able to see from Graham's earlier photo that the card slot comprises a thin stainless steel 'cover' into which is clipped a plastic 'inner', which forms the card mount itself and contains the contacts to link the card to the board. The two parts are held together during construction by very small moulded clips at each corner of the plastic liner. The card slot also contains a fine 'reed microswitch' inside the right-hand side at the back - which closes when a card is installed, telling the board that a card is present. The whole unit (including the 4 case mounting points, 8 separate card contact fingers and the 2 switch contacts) is then surface mounted onto the PCB during manufacture as a single unit.

Unfortunately, this one looks like it must have experienced downwards pressure being applied to the projecting card end at some point, which has dislodged the stainless steel cover from the plastic clips and broken the casing away from the PCB, though the printed circuit board itself looks intact (i.e. the damage hasn't pulled the tracks off the board). The reed switch has, however, become twisted and distorted (probably simply by trying to reinsert a card after the case had unknowingly sprung apart). Unfortunately this means that the only practical 'repair' will be to remove and replace the 'card slot' as a unit.

As an exercise, I have now obtained a replacement card slot and tracked down a friend with the necessary temperature controlled heat-gun equipped solder station to carry out the repair. Now I just need to find the time to give it a go.

Best Regards

Peter

2

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 11, 2024, 08:39:37 am »

Further Update added Thursday Morning at 08.27(UK time)

Hi Guy,

Reflecting on this again in the morning, when I've had a cup of tea and my brain has woken up a bit, the sudden drops in altitude on the track profiles almost certainly reflect drops in connectivity  - either between your phone and available cell towers on your mobile network or between your PilotAware and local ATOM, OGN or other sites, though the reasons for these drops can be complex and warrant further investigation.

I will send you a PM.

Regards

Peter

3

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 10, 2024, 11:24:21 pm »

The Saga Continues!

I had previously disregarded checking via the Ground Station Replay Tool for 6th April as there was no data reported in the PilotAware database for that date - presumably due to the previously reported server issues.

Wrong decision  !

Looking again at the Groundstation Replay Tool with this new information, I can track your aircraft on PilotAware and Cellular heading south-west towards LFLG from just north of Tencin - reporting at that point on screen as at ~ 5000ft, though your virtual radar 'profile' clearly shows your height as 6000ft plus - but with significant altitude fluctuations*. You are reporting from the same point as connected to the LFLG ATOM as you passed over Laval and Saint Mury-Monteymond, then LFLG lost contact with your PilotAware briefly (probably due to terrain) as you passed south of Lac de Freydieres. It picked you up again very briefly as you crossed the D111 Route de Chamrousse for the first time, then seems to have lost contact with you again (on PilotAware) a few seconds later at 10.04 as you were about to cross the Route de Chamrousse for the second time. Your track, however continues via cellular all the way to your landing at Gap Tallard at 10.32.

* at this time of night, I can't remember what the reason for that is - might be a GPS or Baro issue - perhaps Lee can advise.

I  then see you again (via Cellular) taking off from Gap at 13.05 and can follow you all the way back to your landing at Chambery - mainly on cellular, except for a few small breaks in cellular signal from where you pop back up on PilotAware at 13.20 as you pass over the ridge into the valley south of Grenoble and you then drop out of P3i contact again at 13.24 very near the point at which LFLG first picked you up on P3i on your outward flight. Your track then continues (on Cellular only) all the way back to Chambery.

This means that your PilotAware and iGRID were both working as expected during both flights on 6th April, and confirms that PAW uplink is limited along that route (due to terrain) to the area between Tenom and La Petoune de Belledonne and along the Grenoble Valley in close proximity to the only existing ATOM Station at LFLG - which is exactly as I would expect.

Not sure how I can see the aircraft at Gap on 7th April via a Cellular report, though this looks like a genuine report. I guess it must be a glitch in the data.

The (Cellular) reports I see from your aircraft on the ground at Chambery on 8th April are obviously from when you were looking for the local gliders. The only reason I can think of for not seeing any would be that the local OGN station(s), the gliders themselves, or both, hadn't yet updated their software to the new Flarm Protocol, so they weren't 'visible, or available for uplink locally via iGRID.

This now makes much more sense 

Best Regards

Peter

4

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 10, 2024, 06:50:28 pm »

Postscript:

This is a very puzzling case 

Nothing showing on the database for any mode from 38533C from 6th April.

You say that the flights on 7th and 8th April were 'not really flights but ground tests at LFLE (Chambery)' - so I wouldn't expect to find any reports of reception for either of those dates from PWLFLG2 (Grenoble) at 40Km away, which is consistent with my comment that the only reports for those dates were Cellular.

Looking on the PilotAware Playback Site https://playback.pilotaware.com/playback/groundstations/  (...which is based on data collected by the PilotAware ATOM-GRID Network and via iGRID Cellular connection), your aircraft 'pops up' (via its cellular signal) on the ground at Gap Tallard at 16:17 (UTC ?) on 20240407 - a long way from Chambery!! It seems to remain there on the ground at Gap Tallard for about 2 minutes before disappearing 'offline' and I can find no other reports from it that day. In order to get there, by air, you would (presumably) have flown from Chambery right past Grenoble, yet there is no PAW (or ADSB) report on the database from PWLFLG2 to report such a flight. (That is explained by your comments, sent while I was investigating and typing this response, but why would your aircraft show up at Gap Tallard in the first place?)

The next time I can find your aircraft is the following day (20240408), reporting very briefly - again via cellular, but for a few seconds only, back at Chambery at 09:40 UTC before disappearing and reappearing (again via Cellular) apparently heading north past Pontcharra at 09:45. Your comment about the ground tests would explain the unit popping up on the ground at Chambery, but why would it reappear 5 minutes later about 10Km away at Pontcharra - unless that is something to do with the cellular masts that your phone was connecting to during your ground tests.

For completeness, I have just logged in directly to the ATOM at LFLG and it appears to be working normally, reporting both ADSB and Flarm traffic - as I would expect it to.

Hopefully Lee can throw some light on what may be going on.

Best Regards and Bonne Soiree

Peter

5

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 10, 2024, 05:15:03 pm »

Bonjour Encore Guy,

Sorry, been busy the last couple of days so missed your post.

Hello
some news about the Rosetta
in flight the 4 tabs are green, I receive the adsb (airliners) and some aircraft in S/C mode with the yellow rectangle in red or green with their exadecimal addresses.
on the other hand, still no metars or meteo on the surrounding airfields.
I do get clouds on the radar page.
Still no flarms despite the green gsm link.
see you soon
Guy

That is disappointing!

I just had another look at the PilotAware Database. I can see Cellular Reports from 38533C for 20240329, 20240407 and 20240408, but other than those, the most recent ADSB reported from 38533C (by PWLFLG2) was on 20240328 and the most recent PAW (again by PWLFLG2) was way back on 20240128. This makes me wonder if the issue is (at least partly) related to distance and lack of ATOM stations in the area - though we did have a bit of trouble with the servers a week or so ago, so there could be some gaps in our data.

I see Lee (Admin) has asked for your unit's MAC. He has more extensive access to the system than I do, so may be able to find out more about what is going on. In the meantime - bearing in mind that radio and cellular reception will both be affected by terrain obscuration to varying extents while flying in such a mountainous area, - can you remind us how far away (approximately) your airfield at Chambery (LFLE) is from Grenoble (PWLFLG2) and how close (again approximately) you actually got to the ground station at Grenoble during your most recent flights.

Best Regards

Peter

6

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 05, 2024, 10:53:08 am »

Well done Guy!

As I said earlier, I'm pretty sure I have never come across a Bridge coming loose from the GPIO pins in a Rosetta, though I have seen that happen a few times in the PAW Classic - usually because it had been dropped or shaken about by too many heavy landings  .

I'm certainly glad I suggested opening the unit to check though. Good to see it back working again. Every day is a school day as they say.

It's great to get a positive outcome - think we can claim that as a result.

Let me know how it performs once you get back in the air.

A Bientot

Peter

7

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 04, 2024, 04:36:08 pm »

Hi again Guy,

Thanks for the feedback.

Unfortunately, this post is by its very nature somewhat complex, but please bear with me.

From the logging screen messages, my money is still on a barometer failure, but the problem with remote diagnosis is trying to determine whether there is something else going on in the background that is causing the barometer to stop reporting.

If you were in the UK I'd just get you to send it back for testing, or send you a replacement Bridge to swap in, but I have spoken to Ash (who builds, tests and dispatches the units and tells me you have been in touch about installing another ATOM in the South of France). He advises that returning the unit to the UK from France for testing/repair can cause all sorts of problems with Customs (Douaniers) in both countries, so he advises that we should first try to ensure that the problem is definitely with the Bridge and not the Raspberry Pi.

To do this, we need to open the unit and check if there is a correct voltage on the Bridge (supplied from the Raspberry Pi motherboard).

If you are happy to give this a try, you need to proceed as follows...

Power down the unit and remove the power cable, microSD card and the antennas. Next remove the brass nut securing the P3i SMA terminal (which is part of the Bridge board) into the end of the case (nothing will move at this point).

Now open the top cap at the opposite end of the case. If it hasn't been opened before, you will need to split the PilotAware label along the obvious joint line across the top of the case with a sharp blade. Now gently press down the centre of the cap next to the joint to release the single securing clip and you can slide the top cap away from the body.

Having removed the cap, you now need to split the upper part of the case from the lower part. They are held together by two hidden clips along each side of the case. Start with the one which is mid-way between the audio jack socket and the now open top cover. Push a thin blade gently but firmly into the split line and the upper and lower case should pop apart. Try not to force the blade in too hard or you might break the clip. There is a second clip on the same side mid-way between the power and HDMI sockets, which should pop more easily once the first one is open. You can then do the same with the two clips on the opposite side (which are in exactly the same positions) and carefully remove the upper case - slipping it off the P3i antenna connector which you took the brass nut off earlier. You are now looking at the PilotAware Bridge, which is mounted on top of the Raspberry Pi.

The first thing to check is that the Bridge connector at the right side is fully seated onto all 40 pins of the Raspberry Pi GPIO connector (I'd be extremely surprised if it isn't). Next, temporarily refit the antenna to the P3i connector, replace the microSD card and power lead and power up the unit. You should now be able to clearly see the Red 'Power LED' on the motherboard under the P3i antenna connector and the disc activity LED next to it (which flashes green during boot or when writing data to the microSD card, but is otherwise 'unlit'). As the unit boots, you should also see a couple of LEDs start to flash on the underside of the Bridge at the opposite end to the antenna connector, but ignore these for the moment.

First, you will also see 3 sets of test points, one marked 'IN +5v and GND' and two marked 'OUT +5v and GND' . If you have a multimeter, you should be able to get a reading from these test points with your meter on the low voltage scale - mine are all reading 4.95 volts (with the unit powered off a USB battery pack). This will confirm whether the Bridge is receiving power from the Raspberry Pi.

Next go back to the LEDs on the underside of the Bridge. The one nearest the HDMI terminal is the P3i Transmit/Receive indicator, which will briefly flash red to indicate Transmit and Green to indicate Receive of P3i signals (once the Bridge starts functioning). The other LED (next to the RJ45 Ethernet Socket) is the Bridge Status LED (marked Status on the upper surface of the Board). This will initially flash Red 4 times, then used to progressively change to Green Flashes as each of the various stages became active in the same sequence as the list of reports on the Home Screen, so 1090 Rx, P3i T/Rx, Baro and GPS. This was changed some time ago, however, so that the Status LED simply stops flashing Red when each of the 4 stages becomes active, - so NO Green Flashes on the Status LED. I have just checked one of my test units and get 4 Reds at initial boot, then decreasing to zero as each stage becomes active. Having just brought mine back indoors, it has lost its GPS fix, so there is now just a single red flash (which equates to NO GPS as indicating on the Home Screen) then a long pause which equates to 3 'missing' flashes for the other 3 'working' functions, then a single red again for 'No GPS'. In your case, I would expect to see a blank equal to two flashes, then two red flashes in succession, though that depends on whether your unit is seeing any 1090 traffic.

Give this a try and let me know how you get on.

Best Regards

Peter

8

Technical Support / Re: Problem Receiving FLARM with Rosetta (in France)

« on: April 04, 2024, 09:23:03 am »

Bonjour Guy,

Thanks for the feedback. I have now split this off from the previous thread.

The low-voltage report is noted, but shouldn't be the root of the problem as the P3i and Baro were previously showing 'red' without any Voltage Errors reported on your Home Screen.

Let me know once you have loaded and installed a new copy of the software. You may find it useful to reconnect the monitor during the initial boot so you can monitor progress as the software unpacks and loads (it takes about 15 to 20 minutes). Remember to take a note of your setup details (especially your licence key) before changing the card as these will need to be put back in manually once the new software has unpacked and installed - (though you can get them from your earlier screenshot if you forget).

Best Regards

Peter

p.s. I just remembered you have access to the Beta software, so it would be worth updating to the latest 20240205 Beta once you have the new card installed, though I don't expect that to resolve the issue.

9

OGN-R PilotAware / Re: FLARM to change protocol

« on: April 04, 2024, 08:52:01 am »

NOTICE:

To avoid confusion and restrict ongoing posts in this thread to the specific issue of Flarm's protocol change, ongoing posts from Guy (DY691) and others relating to a specific problem receiving Flarm uplinks in France has been split off and moved to a new thread 'Problem Receiving FLARM with Rosetta (in France)' in the 'Technical' section of the Forum, see here...

 http://forum.pilotaware.com/index.php/topic,2368.msg24449.html#msg24449

Peter
(Forum Moderator)

10

Technical Support / Re: Problem Receiving FLARM With Rosetta in France

« on: April 03, 2024, 04:03:49 pm »

Bonne Apres-midi, Guy,

Hmm!

No PW  ATOM at LFLE unfortunately.

Looking again at your original post, together with the 'error' reports on the 'Logging Screen', and the fact that both the 'P3i' and the 'Barometer' are reporting as 'Unavailable' on the 'Home' screen, there could be a connection between these and your lack of Flarm uplinks via P3i - especially if you have been flying within range of LFLG.

The P3i transceiver and the barometric pressure cell are both mounted on the PilotAware 'Bridge' and if, for example, the unit isn't getting a '3D' GPS fix (which yours says it was - at least at the time you took the screenshots), or the GNSS altitude (GPS based altitude) doesn't match the reported barometric altitude within defined limits or no barometric altitude is available due for example to a software issue or a defective Baro Module - the Bridge won't transmit P3i, which in turn won't trigger the LFLG ATOM into 'Uplink Mode', so you won't get their Flarm data -except potentially via iGRID, though that still might not report if the system hasn't been able to calculate your altitude. That would certainly account for you not receiving Flarm Uplinks from LFLG.

Unfortunately, the only easy way to tell if your Rosetta is transmitting is to check it locally against another Pilotaware, or run it near a local ground station and get me to check the database afterwards to see if its transmissions have been received.

Although this could, as I have said, indicate a Bridge fault, the Bridge is usually extremely reliable and if it isn't working, it is much more likely to be due to a corruption of the software such as due to a defective microSD card, so before thinking about replacing the Bridge, it would be worth carrying out a few simple tests as follows...

Firstly, (with the unit powered down) check that the MicroSD card is fully seated in its slot (between the two antenna connectors). It is a simple slide out - and push carefully back in. If you can then connect your Rosetta to a monitor (or TV screen) via the Rosetta's HDMI socket, power up the Rosetta and check that it runs right through the 'boot' sequence without showing any obvious errors on the monitor. You don't need to read everything - just look for any obvious error messages. If the boot sequence gets to the point where the screen stops and reports 'Login' that is the sequence finished and the unit should now be running. You should now be able to 'log in' to the PAW WiFi and check if the P3i and Barometer are still reporting 'Unavailable' or if they have gone green.

If necessary repeat the test by rebooting the unit outside with a clear view of the sky so it can get a good view of GPS satellites -  then log in to the PAW WiFi with your phone or tablet and check again.

If there is still a problem, the next thing to try would be to load a new copy of the latest PAW software -available from https://pilotaware.lode.co.uk - and preferably loading it onto a new microSD card. If necessary, I can talk you through this process if we get to that point.

If the P3i and Barometer are still 'Unavailable' after loading new software, I would suggest returning your unit to PilotAware Support for full investigation, but try the simple tests first and let us see how we get on.

Best Regards

Peter

p.s. Let me know when you have read this, and I will split this discussion off into a new thread and leave Lee's original thread for issues directly related to the Flarm Protocol Update.

11

Technical Support / Re: Problem Receiving FLARM With Rosetta in France

« on: April 02, 2024, 07:31:25 pm »

Hi DY691,

While your antenna swap won't 'improve' reception, it does imply that there is no continuity issue with the longer 869.5MHz antenna - which should go back on the P3i connector.

I have just checked the PilotAware database and your aircraft (HexID 38533C) was certainly transmitting P3i on 20231123, 20231207 and 20240128 if that helps - all received at site LFLG2 at ranges up to 30Km. There are no more recent reports recorded, but that might just reflect some problems we have had with recent efforts to upgrade the PilotAware servers.

I see from the database, that apart from a couple of reports from Versoud in early 2021, all of your reported P3i transmissions are from LFLG2, which seems to be the only ATOM site you have been within range of. That of course reflects the lack of ATOM sites in France. I'm guessing therefore that in the past, most of the Flarm Traffic you have been receiving has been via SafeSky. That being the case, it might be in your interest to consider promoting further ATOM development in the areas you fly. If you are interested in helping to expand the network, please get in touch via atom@pilotaware.com and mention my name.

LFLG2 by the way is currently 'active' and running the updated 20240321 firmware, - which includes the updated Flarm Protocol, so you should see directly rebroadcast Flarm traffic, provided both it and yourself are in range of that site and provided the protocol has been updated in the relevant local Flarm Units.

If you continue to have problems please get back in touch.

Best Regards

Peter

12

Technical Support / Re: Just set up iGrid and get momentary voltage errors

« on: April 01, 2024, 11:00:32 am »

Hi Kev,

Correct and they do usually work fine, - as you are seeing from the fact that you have iGRID running.

I'm not saying it won't, or isn't working, just that it is the 'new variable' in the setup, so the most likely to have resulted in the voltage error being displayed - unless you had voltage errors previously but just didn't notice them?

Try removing the dongle again (power down first - it's not good to swap WiFi dongles in or out with the system running), then reboot and see if the warning comes back. Then try gently wiggling the power lead at the microUSB connection - while monitoring the Home Screen for Voltage errors and also watching for the red power LED on the main board just below the P3i antenna socket - it's a bit difficult to see, but it (or at least the glow from it) should be visible through the slots at the side to the left of the power socket. The LED should stay solid red. Any dropouts or voltage error messages and you probably have a defective microUSB socket or cable. If this doesn't reproduce the fault, power down again and replace the dongle. If the error then returns it must be the dongle that is causing it.

Regards

Peter

13

Technical Support / Re: Just set up iGrid and get momentary voltage errors

« on: March 31, 2024, 08:45:47 pm »

Hi Kev,

While old 'Classic' WiFi dongles 'can' work as iGRID dongles, they use a different configuration to the newer dongles which are supplied specifically for that purpose. (Likewise the newer iGRID WiFi Connectivity Dongles will NOT work as primary WiFi dongles on PAW Classics.

My guess would be that although your old dongle appears to be working as an iGRID access dongle, it could well have degenerated in use (in the Classic) and be drawing higher than expected current, hence causing a reported drop in the PAW supply voltage, which will have knock-on effects as it is obviously throttling back the processor on the Pi. This is not unusual with older WiFi or SDR dongles that have had a lot of use.

Unfortunately the only way to tell for sure is to swap it out with another 'known good' dongle and see if the voltage errors go away.

My advice would be to buy and try one of the iGRID WiFi Connectivity Module dongles  available from the PAW Shop at https://www.pilotaware.com/product/igrid-wifi-connectivity-module

Please let us know if that resolves the issue.

Best Regards

Peter

14

Technical Support / Re: Dead Rosetta - SD card slot has come adrift

« on: March 31, 2024, 08:15:48 pm »

Hi again Graham,

I have PM'd you.

Peter

15

Technical Support / Re: Dead Rosetta - SD card slot has come adrift

« on: March 31, 2024, 08:49:51 am »

Hi Graham,

Thanks for posting - that's certainly a new one on me. I have come across a few dodgy microUSB sockets (including one of my own, which Jeremy kindly replaced for me), but have never come across a microSD slot casing become detached before.

The obvious cause would be downwards pressure (away from the printed circuit board) applied to the socket, such as if, for example, the Rosetta case was disassembled without first removing the microSD card - but that usually breaks the end off the card, not the socket. To force the socket off the board would require considerable leverage - unless of course the solder joints were already weak.

As the actual contacts are all on the PCB itself, it should just be a case of re-soldering the two front case mounts back onto the PCB - unless the force has lifted the solder tracks off the board. in which case there wil be nothing to solder to.

A replacement Raspberry Pi3B (not Pi3 B+ *) if you can find one, is the obvious fix, or a resolder if the tracks on the board are still intact. I have just swapped a Classic for a customer to an unused Pi3B which he got from eBay, so they can still be found. If you swap the Pi, remember to advise Ash (support@pilotaware.com) of the new MAC address and he will issue a new licence code for any remaining licence period.

* I run a Pi3B+ on one of my 'test' units. It will work, (though not officially supported) and draws a a fair bit more current than the 3B in use (though still well within the capability of your Charge2.

Please let us know how you get on.

Oh and OK on your comments re SE2.

Best Regards

Peter