So far I snagged 13 workunits. Out of all 13, 12 were blanked. The only one that wasn't blanked was a resend for a validation inconclusive.

If so, it still doesn't allay my fears of a possible antenna or recorder problem rendering all tapes from 2016 as useless for Astropulse.

@Richard

I'm a little late to the party on this because I haven't paid attention to this thread in a long time. However, after seeing your comment, I just went back and reviewed all the 2016 APs that I got last month, 158 of them, and didn't really see any cause for concern. The only APs that were 100% blanked were the 27 from the 15fe16a* tapes (where you found that Arecibo was likely targeting the moon), along with 7 from that pesky B3_P1 receiver (or whatever that designation means). I also had 5 with 30/30 overflows, but no pattern to the sources. The rest looked fine, from 06au16a*, 07au16a*, 10au16a*, 11au16a*, 12au16a*, 12au16a*, 13au16a*, 13au16a*, 27jl16a*, 28jl16a*, 28jl16a*, and 28jl16a*. That works out to 13 different tapes from 8 different days.

EDIT: A quick look at a sampling of the January and February, 2016, APs that I got early this month, however, seems to indicate that almost all of those were 100% blanked. I'll try to take a more in-depth look at those tomorrow. It looks like the dates on those run from mid-January to early February.

A quick look at a sampling of the January and February, 2016, APs that I got early this month, however, seems to indicate that almost all of those were 100% blanked. I'll try to take a more in-depth look at those tomorrow. It looks like the dates on those run from mid-January to early February.

A quick look back here shows that most of the Nov 2015 stuff was OK, but most of the Dec 2015 stuff is blanked.

---

A quick look at a sampling of the January and February, 2016, APs that I got early this month, however, seems to indicate that almost all of those were 100% blanked. I'll try to take a more in-depth look at those tomorrow. It looks like the dates on those run from mid-January to early February.

A quick look back here shows that most of the Nov 2015 stuff was OK, but most of the Dec 2015 stuff is blanked.

I've received four more AP tasks from November 2015, and they're all non-compressible.

---

If so, it still doesn't allay my fears of a possible antenna or recorder problem rendering all tapes from 2016 as useless for Astropulse.

@Richard

I'm a little late to the party on this because I haven't paid attention to this thread in a long time. However, after seeing your comment, I just went back and reviewed all the 2016 APs that I got last month, 158 of them, and didn't really see any cause for concern. The only APs that were 100% blanked were the 27 from the 15fe16a* tapes (where you found that Arecibo was likely targeting the moon), along with 7 from that pesky B3_P1 receiver (or whatever that designation means). I also had 5 with 30/30 overflows, but no pattern to the sources. The rest looked fine, from 06au16a*, 07au16a*, 10au16a*, 11au16a*, 12au16a*, 12au16a*, 13au16a*, 13au16a*, 27jl16a*, 28jl16a*, 28jl16a*, and 28jl16a*. That works out to 13 different tapes from 8 different days.

EDIT: A quick look at a sampling of the January and February, 2016, APs that I got early this month, however, seems to indicate that almost all of those were 100% blanked. I'll try to take a more in-depth look at those tomorrow. It looks like the dates on those run from mid-January to early February.

Well, that was a thoroughly unrewarding exercise. Out of 143 AP tasks from 2016 tapes that my hosts processed in early September, 100% of the channels for 100% of the dates were 100% blanked. Tapes represented were all from the mid-January to early February time period: 02fe16aa, 03fe16aa, 12ja16aa, 15ja16aa, 17ja16aa, 18ja16aa, 19ja16aa, 20ja16aa, 21ja16aa, 22ja16aa, 23ja16aa, 24ja16aa, 26ja16aa, 27ja16aa, 28ja16aa, 29ja16aa, and 30ja16aa. Perhaps worth noting is that all were "aa" tapes. Could it be that the only data collected on those days were brief observations of a single target? That lunar meteoroid-strike EMP proposal only requested 4 observing periods, though.

One good out of 22 processed. Shooting blanks.

---

"Sour Grapes make a bitter Whine." <(0)>

Well, that was a thoroughly unrewarding exercise. Out of 143 AP tasks from 2016 tapes that my hosts processed in early September, 100% of the channels for 100% of the dates were 100% blanked. Tapes represented were all from the mid-January to early February time period: 02fe16aa, 03fe16aa, 12ja16aa, 15ja16aa, 17ja16aa, 18ja16aa, 19ja16aa, 20ja16aa, 21ja16aa, 22ja16aa, 23ja16aa, 24ja16aa, 26ja16aa, 27ja16aa, 28ja16aa, 29ja16aa, and 30ja16aa. Perhaps worth noting is that all were "aa" tapes. Could it be that the only data collected on those days were brief observations of a single target? That lunar meteoroid-strike EMP proposal only requested 4 observing periods, though.

I know the feeling. But I've noticed before that sometimes a batch of mostly aa tapes are loaded one week, mostly ab another week - they aren't processed in strict recording order. I'll have a look at who was using the ALFA receiver on those nights, and see if it makes any more sense.

But your numbers gave me another idea, so I looked and found task 5135710370 in your pending list. Very strangely, ap_22ja16aa_B5_P0_00129_20160903_15963 compresses to 6,876 KB in zip format - not typical of a stuck bit, but not typical of a normal AP data file, either. I'll look and see if I can find any other examples not deleted yet.

But ap_12ja16aa_B4_P1_00292_20160902_24156.wu is normal - barely compressible.

No lunar studies in your list.

12ja16aa	A3026 (M-dwarf stars), A2754 (Zone of Avoidance)
15ja16aa	no ALFA scheduled
17ja16aa	no ALFA scheduled
18ja16aa	no ALFA scheduled
19ja16aa	A2754
20ja16aa	P3055 (FRB130628), A2754
21ja16aa	A3026, A2754
22ja16aa	P3055
23ja16aa	A2754
24ja16aa	P3055, A3022 (Virgo Extragalactic Survey)
26ja16aa	A2754
27ja16aa	P3055, A2754
28ja16aa	P3055, A2754
29ja16aa	P3055, A2754
30ja16aa	P3055
02fe16aa	P3055, A2754
03fe16aa	P3055, A3022, A2754

Those "no ALFA scheduled" look interesting, since we've obviously got data from those 3 dates. Hmmmm....

You're probably right about those "aa" tapes eventually being followed by "ab", etc., at a later date. Some of those "aa" tapes are still on the SSP to be split for MB and they all look like full ones (50.20 GB). I doubt if all those dates just happen to have exactly the right amount of data to fill just one tape.

I was also just looking at some of the MB tasks that my hosts have completed from the January and February data that was 100% blanked for AP, curious to see if there was any correlation with the MB results. I can't say that I see any. Some are overflows, some aren't.

02fe16aa
Task 5167397389 returned 1 Spike, 1 Autocorr

03fe16aa
Task 5167570635 overflowed w/ 30 Pulses

15fe16ab
Task 5165731675 (VLAR) returned 4 Spikes, 1 Autocorr, 9 Pulses and 1 Triplet
Task 5164704402 (VLAR) overflowed with 28 Autocorrs and 2 Pulses

15fe16ac
Task 5165873621 returned 2 Autocorrs and 2 Triplets

15ja16aa
Task 5168998647 overflowed w/ 30 Pulses
Task 5169973788 returned 5 Spikes, 1 Autocorr and 1 Triplet

Maybe with a bigger sample, a pattern would emerge, but so far I'm not seeing any correlation between the RFI in the AP WUs and the noise levels in the MB WUs.

10 out of 11 WUs ranging from 18no15 to 27no15, plus one 20dc15 are blank.  The sole non-blank is from 03no15.

The sole non-blank is from 03no15.

But still very noisy, hitting the limit of 30 repetitive pulses. That's pretty much what I've seen with the few of mine that weren't 100% blanked in the most recent batch. Some of them hitting 30 for both, but all hitting 30 for repetitive pulses.

An AP app for Android would be nice. [snip] since there are millions of Android tablets and phones out there, that could run AP's too.

+5 (...since I have five of them....)

---

An AP app for Android would be nice. [snip] since there are millions of Android tablets and phones out there, that could run AP's too.

+5 (...since I have five of them....)

Question. How long does a middle-of-the-road MB (around 0.44 angle range) take on those devices? I don't know for sure, but multiply that by about 20x and that's how long an AP will likely take.

If it can't be done in under ~24 days, the scheduler will never send you one since you won't be able to turn it around within the 25-day deadline window.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

My Android takes between 12 and 24 Hrs to run an Mb ... But it's a broken reject phone from my wife ...

Ed F

My ARM-based tend to take 24 or 48 hours (rough approximation), while my 1 Intel Atom takes 6,9, or 12 hours, depending on the task.

---

I sent a message to Eric yesterday asking where he was on splitting AP tasks from the Guppi data.
No response yet.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I sent a message to Eric yesterday asking where he was on splitting AP tasks from the Guppi data.
No response yet.

Thank you for sending him a message. I look forward to hearing the response

---

I suspect we will see them on BETA first, and as far as I'm aware there haven't been any over there yet (But I'd will be really pleased to hear otherwise)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

a new trickle is coming down.

Ed F

I don't think guppies are going to get split into AP units this year. There is no code in the svn to indicate they have started working on v8, one of the primary reason is being not enough manpower