Форум: Техническая поддержка

В одном из предыдущих сообщений речь шла о замеченных странностях в работе E20-10.
Эти странности нам практически полностью удалось устранить заменой источника питания.
Но некоторые странности, как выяснилось, всё же остались...

Эти странности встречаются очень редко и по сути дела не оказывают существенного влияния
на результаты наших экспериментов. Но всё же хотелось бы понять суть проблемы, сделать
эксперименты полностью "чистыми" и исключить возможные сюрпризы, когда проблема сможет
проявиться более заметно.

Описание проблемы.

Используется схема эксперимента, приведённая в статье в разделе "Примеры внедрения".

Модуль LTR34 по одному каналу генерирует медленную синусоиду (амплитуда около 1 В, период около 30 секунд),
по другому каналу - константу 0 В.

Модуль E20-10 осуществляет сбор информации на частоте 10 МГц, управляющая таблица состоит из 4 элементов:

adcPar.t2.SynchroType = INT_START;
adcPar.t2.SynchroSrc = INT_CLK;
adcPar.t2.AdcIMask = SIG_0|SIG_1|SIG_2|GND_3;
adcPar.t2.DigRate = 0;

adcPar.t2.NCh = 4;
adcPar.t2.Chn[0] = 2; // BNC3 (координата Y)
adcPar.t2.Chn[1] = 6; // SYNC
adcPar.t2.Chn[2] = 1; // BNC2 (координата X)
adcPar.t2.Chn[3] = 6; // SYNC

В представленном примере эксперимента всего было записано 68074037247 кадров.
Ниже представлена статистика по этой записи.

На первый взгляд можно предположить, что строчки, соответствующие значениям в первом столбце
от -2370 до -2322, соответствуют случайным выбросам за "нижний край" синусоиды.

Но по непонятной причине все такие выбросы встречаются кратное 4 количество раз.
И во всех этих случаях (и только в этих) наблюдается полное отсутствие активности ФЭУ
(хотя у ФЭУ должны быть как минимум темновые срабатывания).

Всё это наводит на мысль, что речь в данном случае идёт не о реальных результатах
семплирования, а о "псевдоданных", которые возникают в потоке данных в результате какой-то
ошибки, да ещё и размножаются в четырёх экземплярах.

Возможно, такие артефакты встречаются и при других значениях, соответствующих элементу t2.Chn[1]
управляющей таблицы, но они незаметны на фоне большого количества корректных результатов измерений.

PS. У нас имеются все исходные записи экспериментов. Можем предоставить их для анализа
(один эксперимент - сотни Гб) или проанализировать самостоятельно по вашим указаниям.

столбец 1: результат измерений по входу BNC2 (элемент t2.Chn[2] управляющей таблицы)
столбец 2: общее количество кадров, зарегистрированных с таким значением (указанным в столбце 1)
столбец 3: общее количество единичных битов среди младших 12 бит данных с цифрового входа SYNC (t2.Chn[1] и t2.Chn[3]) во всех кадрах, соответствующих данной строке

========================================

-2370	4	0
-2369	0	0
-2368	4	0
-2367	0	0
-2366	0	0
-2365	0	0
-2364	0	0
-2363	0	0
-2362	0	0
-2361	0	0
-2360	0	0
-2359	0	0
-2358	4	0
-2357	0	0
-2356	4	0
-2355	8	0
-2354	0	0
-2353	0	0
-2352	8	0
-2351	0	0
-2350	0	0
-2349	0	0
-2348	4	0
-2347	4	0
-2346	0	0
-2345	0	0
-2344	12	0
-2343	4	0
-2342	4	0
-2341	4	0
-2340	4	0
-2339	4	0
-2338	4	0
-2337	8	0
-2336	4	0
-2335	0	0
-2334	8	0
-2333	4	0
-2332	4	0
-2331	0	0
-2330	8	0
-2329	0	0
-2328	0	0
-2327	12	0
-2326	16	0
-2325	16	0
-2324	4	0
-2323	8	0
-2322	8	0

=== странный фрагмент заканчивается тут, далее несколько фрагментов для примера, разделённых знаком ... ===

-2321	76	0
-2320	212	4
-2319	1225	12
-2318	5529	8
-2317	19623	24
-2316	59718	121
-2315	151455	376
-2314	309143	948
-2313	511893	1284
-2312	812537	2108
-2311	1096241	2766
-2310	1470299	3528
-2309	2012888	4845
-2308	2856715	7386
-2307	5019577	12923
-2306	11253833	28618
-2305	25718508	65950
-2304	59703856	151118
-2303	108569856	276247
-2302	164732655	412104
-2301	199186040	494373
-2300	223093307	544068
-2299	209615117	509201
-2298	186623376	456168
-2297	159169002	388632
...
-37	9036829	3759995
-36	9457327	3935891
-35	9376750	3918106
-34	9306209	3894719
-33	8999261	3780091
-32	9601028	4038815
-31	9279908	3912360
-30	9286250	3925211
-29	8986400	3806141
-28	9449123	4012292
-27	9322352	3957954
-26	9256917	3933037
-25	8919011	3796354
-24	9495800	4044794
-23	9266534	3953960
-22	9297500	3972468
-21	8987670	3844881
-20	9444379	4052644
-19	9388186	4039313
-18	9316970	4017661
-17	8831536	3798838
-16	9407475	4054336
-15	9039990	3896520
-14	8977229	3878651
-13	8690081	3761242
-12	9181306	3977957
-11	9161424	3966079
-10	9190178	3982973
-9	8937986	3883404
-8	9505261	4132334
-7	9268531	4030383
-6	9226062	4001857
-5	8888592	3857853
-4	9374227	4067699
-3	9980404	4333677
-2	9398787	4077768
-1	8798648	3816191
0	9361097	4065297
1	9222134	4004508
2	9260404	4023563
3	8967543	3909011
4	9416331	4097509
5	9314677	4059064
6	9307480	4052235
7	9017798	3931748
8	9577705	4167000
9	9301869	4062937
10	9283754	4059351
11	8966035	3912009
12	9453500	4123277
13	9415036	4088377
14	9336961	4048710
15	8963486	3875542
16	9490072	4100091
17	9225084	3992413
18	9235248	3995960
19	8934390	3848489
20	9394507	4044716
21	9316167	4019865
22	9293753	4001415
23	8985975	3858078
24	9536833	4100372
25	9275006	3975354
26	9284243	3990820
27	8982874	3855918
28	9435764	4031141
29	9360690	3980466
30	9266836	3942205
31	8952614	3811642
32	9590356	4081483
33	9270122	3930916
34	9280987	3931320
35	8974655	3790126
36	9419776	3974538
37	9326078	3925499
38	9291888	3910720
39	8958887	3757897
40	9507708	3983063
41	9263843	3888526
42	9292456	3890032
43	8990745	3743757
44	9397866	3902808
45	9294090	3839194
46	9192428	3793421
47	8779297	3628656
48	9441120	3882404
49	9187724	3772844
...
2328	46945067	78274
2329	19399062	32760
2330	8214273	13704
2331	3906053	6590
2332	2439565	4311
2333	1617421	2756
2334	1168527	1770
2335	844319	1398
2336	640988	1052
2337	389614	640
2338	203339	488
2339	84752	120
2340	31065	48
2341	8338	12
2342	2041	4
2343	391	0
2344	68	0
2345	8	0
2346	8	0

Здравствуйте, Алексей.
Понятно, что описанный Вами эффект находится ниже порога разрешения данного тракта измерения на основе E20-10. И, изучая статистику на больших выборках, вполне можно обнаружить, в т.ч,  неслучайные процессы (вероятно, не только вызванные особенностями E20-10). Описанный Вами эффект чем-то напоминает радиотехнический эффект детектирования сигнала на нелинейности тракта передачи преобразователя. В данном случае, эффект - численный (арифметический) может быть связан с целочисленной реализацией коррекции данных внутри E20-10 (если специально анализировать гистограмму распределения кодов собственного шума АЦП, то этот эффект будет виден). А что тогда детектируется на этой нелинейности? - любые неслучайные помехи, попавшие в тракт измерения (например, частота сети, эффекты, связанные со ступенчатостью сигнала на выходе ЦАП LTR34, биения частот преобразования E20-10 и LTR34, и т.д.). Я Вам рекомендую отключить собственную коррекцию данных E20-10 и повторить эксперимент. Но, возможно, это не поможет, поскольку у любого АЦП "линейного приближения" всегда существует собственная ощутимая дифференциальная нелинейность преобразования...
Кроме того, я надеюсь, что Вы контролируете программно то, что не происходит переполнения внутреннего буфера E20-10 (при переполнении E20-10 будет отбрасывать куски данных, кратные кадру по размеру, и это может как-то повлиять на статистику).

[Аппаратная коррекция показаний АЦП была отключена (забыл об этом написать).

Более детальный анализ данных выявил следующую ситуацию.

1. В достаточно редких случаях происходит повтор одних и тех же кадров
по 4 раза с "расстоянием" между повторяемыми кадрами внутри четвёрки 8192 кадра.

2. В абсолютно всех таких случаях не зафиксировано ни одного бита цифрового
канала SYNC (второе и четвёртое значение ив кадре; т. е. или эти биты мешают проявлению
ошибки, либо в результате проявления ошибки обнуляются).

Ниже приводятся примеры.

Обозначения:
столбец 1 - номер п/п
столбец 2 - номер кадра (нумерация с 0)
столбцы 3, 4, 5, 6 - содержимое кадра в десятичном формате
столбец 7 - разница номера кадра с номером кадра из предыдущей строки

Пример 1. X=-2370. Это минимальное значение X во всей выборке, повторы образуют одну четвёрку.

1   21717914675  -13 0 -2370 0
2   21717922867  -13 0 -2370 0    8192
3   21717931059  -13 0 -2370 0    8192
4   21717939251  -13 0 -2370 0    8192

Пример 2. X=-2321. Максимальное количество четвёрок повторов (19 штук).

1   1958056534  12 0 -2321 0
2   1958064726  12 0 -2321 0    8192
3   1958072918  12 0 -2321 0    8192
4   1958081110  12 0 -2321 0    8192
5   3998880738  7 0 -2321 0    2040799628
6   3998888930  7 0 -2321 0    8192
7   3998897122  7 0 -2321 0    8192
8   3998905314  7 0 -2321 0    8192
9   5889528213  12 0 -2321 0    1890622899
10   5889536405  12 0 -2321 0    8192
11   5889544597  12 0 -2321 0    8192
12   5889552789  12 0 -2321 0    8192
13   10005420539  8 0 -2321 0    4115867750
14   10005428731  8 0 -2321 0    8192
15   10005436923  8 0 -2321 0    8192
16   10005445115  8 0 -2321 0    8192
17   17604873204  9 0 -2321 0    7599428089
18   17604881396  9 0 -2321 0    8192
19   17604889588  9 0 -2321 0    8192
20   17604897780  9 0 -2321 0    8192
21   24078622490  9 0 -2321 0    6473724710
22   24078630682  9 0 -2321 0    8192
23   24078638874  9 0 -2321 0    8192
24   24078647066  9 0 -2321 0    8192
25   25028728011  7 0 -2321 0    950080945
26   25028736203  7 0 -2321 0    8192
27   25028744395  7 0 -2321 0    8192
28   25028752587  7 0 -2321 0    8192
29   25656956387  12 0 -2321 0    628203800
30   25656964579  12 0 -2321 0    8192
31   25656972771  12 0 -2321 0    8192
32   25656980963  12 0 -2321 0    8192
33   28793772617  9 0 -2321 0    3136791654
34   28793780809  9 0 -2321 0    8192
35   28793789001  9 0 -2321 0    8192
36   28793797193  9 0 -2321 0    8192
37   30045019236  8 0 -2321 0    1251222043
38   30045027428  8 0 -2321 0    8192
39   30045035620  8 0 -2321 0    8192
40   30045043812  8 0 -2321 0    8192
41   30357001282  11 0 -2321 0    311957470
42   30357009474  11 0 -2321 0    8192
43   30357017666  11 0 -2321 0    8192
44   30357025858  11 0 -2321 0    8192
45   37820733731  12 0 -2321 0    7463707873
46   37820741923  12 0 -2321 0    8192
47   37820750115  12 0 -2321 0    8192
48   37820758307  12 0 -2321 0    8192
49   39084852685  12 0 -2321 0    1264094378
50   39084860877  12 0 -2321 0    8192
51   39084869069  12 0 -2321 0    8192
52   39084877261  12 0 -2321 0    8192
53   45401050693  8 0 -2321 0    6316173432
54   45401058885  8 0 -2321 0    8192
55   45401067077  8 0 -2321 0    8192
56   45401075269  8 0 -2321 0    8192
57   46986823856  13 0 -2321 0    1585748587
58   46986832048  13 0 -2321 0    8192
59   46986840240  13 0 -2321 0    8192
60   46986848432  13 0 -2321 0    8192
61   48261958987  8 0 -2321 0    1275110555
62   48261967179  8 0 -2321 0    8192
63   48261975371  8 0 -2321 0    8192
64   48261983563  8 0 -2321 0    8192
65   59999820575  9 0 -2321 0    11737837012
66   59999828767  9 0 -2321 0    8192
67   59999836959  9 0 -2321 0    8192
68   59999845151  9 0 -2321 0    8192
69   60002210085  4 0 -2321 0    2364934
70   60002218277  4 0 -2321 0    8192
71   60002226469  4 0 -2321 0    8192
72   60002234661  4 0 -2321 0    8192
73   64698522385  12 0 -2321 0    4696287724
74   64698530577  12 0 -2321 0    8192
75   64698538769  12 0 -2321 0    8192
76   64698546961  12 0 -2321 0    8192

Буквально отсчёты данных повторяются этих кадрах?

Да. Кадр, через 8192 кадра точно такой же кадр, ещё через 8192 - опять точно такой же, и ещё через 8192 - ещё опять точно такой же.

Т. е. в разных четвёрках информация разная, а внутри одной четвёрки - точные повторы по 4 раза на расстоянии 8192 кадра друг от друга.

Алексей, тогда это не "подозрительная ситуация", а явная проблема, которую нам нужно искать.   
Эффект на разных экземплярах E20-10 проявляется? 
Сейчас Вам под Linux доступна низкоуровневая возможность E20-10 "Включение режима подстановки тестовой последовательности данных вместо данных АЦП."?
Если да, могу рассказать, как протестировать  E20-10 на непрерывность данных в Ваших условиях... В любом случае, подобный тест оборудования будет полезен на будущее.

Сейчас в связи с карантином у меня нет доступа на рабочее место.
Мне удалённо доступен управляющий компьютер со всем архивом измерений, но подключённая к нему аппаратура (в т. ч. E20-10) обесточена.

Соответственно, могу что-то делать с архивами. Напрашивается мысль проверить их на автокорреляцию со смещением 8129 кадра. Возможно, вы ещё что-нибудь посоветуете.

Про тестовую последовательность вместо данных АЦП мне известно не было. Естественно, прошу объяснить, как эта возможность включается и используется. Попробую при первой возможности это применить (как только в лаборатории окажутся сотрудники - попрошу их включить E20-10).

Большинство измерений выполнено с одним экземпляром E20-10. Этот тот экземпляр, который был получен с предыдущим заказом на доработку прошивки (добавление синхронных цифровых каналов). Это делалось специально, чтобы были сравнимые данные между разными экспериментами.

Тестовые метрологические эксперименты в одинаковых условиях, но с разными экземплярами E20-10 также выполнялись и скорее всего эти записи сохранились. Но их поиск сейчас (в удалённом режиме работы) несколько затруднён. Как найдётся - я обязательно проверю наличие обсуждаемого выше эффекта на записях с других экземпляров E20-10.

Алексей, желательно подтвердить, что эффект был и на другом экземляре E20-10 (не важно, с какой прошивкой), чтобы исключить специфическую неисправность одного экземпляра.

Алексей, в любом случае, я попрошу наших программистов предоставить в том или ином виде пользователям нашу технологическую  возможность включать в FPGA Е20-10 специальный режим подстановки: вместо данных преобразователя LTC2245 - счетчик по модулю счета,  некратный степени 2. Это позволит в неизменных условиях пользователю протестировать весь аппаратно-программный интерфейс на непрерывность данных.

А возможно ли в таком случае сделать возможность контроля целостности реальных данных?

Сделать это можно, например, так. Выдавать реальные данные с АЦП, но параллельно вести нумерацию отсчётов АЦП. И по запросу по control pipe выдавать пару: какой-нибудь уже пронумерованный отсчёт АЦП и присвоенный ему номер. Тогда по результатам таких периодически выполняемых запросов можно будет находить в потоке данных эти пронумерованные отсчёты на данном расстоянии (с данной разностью номеров) и убеждаться, что нумерация не сбивается. [А если есть такая техническая возможность - лучше выдать несколько отсчётов АЦП подряд - например, десяток.]

Вообще, при получении достаточно значимого научного результата у оппонентов всегда возникают возражения: что дело тут не в физике, а в некорректной обработке экспериментальных данных. Так было и в этом случае. Коллеги заметили незначительные шероховатости, расследование причин которых привело в итоге к обнаружению факта редкого удвоения (точнее, учетверения) информации в потоке данных. Поэтому добавление такой возможности нумерации отсчётов АЦП сделало бы E20-10 существенно более ценным для научных исследований.

Алексей, спасибо за предложения. В любом случае, те или иные средства контроля целостности данных можно будет вводить в E20-10 рев.С - там для этого имеется свободный логический ресурс в FPGA. Конкретно Ваш способ контроля целостности данных зависим от значений отсчётов АЦП - в общем случае этот подход нельзя назвать корректным. Пожалуй, здесь возможен классический подход - вести в поток данных специальное слово CRC (например, для каждых 1024 отсчётов АЦП). Это слово CRC должно быть вне логики кадра данных от E20-10 (например, CRC должно аппаратно вставляться в поток после 1024-го отсчёта АЦП, и изыматься из потока для проверки целостности данных на уровне API). Увеличение максимального трафика передачи данных, скажем, на доли процента за счёт введения CRC не должно повлиять на устойчивость сбора данных.

Тогда ещё 2 предложения.

1. Сделать CRC доступным пользователю. Чтобы пользователь в процессе обработки данных мог самостоятельно пересчитать CRC и сравнить с полученным из E20-10. Это позволит исключить ошибки API и самого пользователя. (А также указать на наличие такого контроля в научной публикации, что сразу снимет вопросы при рецензировании.)

2. Вести сквозную нумерацию всех блоков расчёта CRC и передавать вместе с CRC его номер. Это позволит отследить ситуации пропажи блока целиком или же его появления несколько раз.

Тогда уж CRC 2-го уровня нужно вводить (как циклическая сумма предыдущих CRC 1-го уровня). Это уж точно лучше счётчика блоков. Научному сообществу это больше понравится, наверное.

Алексей, но с практической точки зрения, конечно, Вы правы - сквозная нумерация блоков лучше в ситуации потери (порчи) блока: итерационно можно обнаружить CRC следующего блока  и по номеру блока понять, сколько блоков потерялось.
Справедливости ради замечу, что упомянутая выше технология замещения данных АЦП счётчиком у нас используется при тестировании каждого экземпляра E20-10 на непрерывность данных при производстве. Но при производстве каждому экземпляру невозможно устраивать длительные тесты.
И, ещё раз напомню, что необходимым условием непрерывности данных E20-10 является отсутствие программно обнаруживаемых переполнений внутреннего FIFO E20-10 (на основе SDRAM). Если вы подозреваете, что в потоке данных E20-10 имеются разрывы или повторы кадров, то одновременно следовало бы сообщить техподдержке: были ли обнаружены переполнения внутреннего буфера E20-10? Если были переполнения, то это - нерабочий (нештатный) режим системы сбора данных (компьютер не успел откачать данные FIFO E20-10 и произошло его переполнение). Если не были переполнения, то режим -  рабочий. - Это совершенно разные случаи для рассмотрения возможных причин обнаруженных эффектов.
Алексей, это важно и для Вас. Например, взаимосвязь времени обнаруженных переполнений буфера и участков, где нарушается статистика при обработке данных, сразу позволила бы Вам очистить собранные данные от невалидных участков... Однако, эту взаимосвязь по времени нужно рассматривать с определённой долей асинхронности программного получения данного  признака переполнения.

Отредактировано Инженер (25.04.2020 09:03:13)

Разрывы данных иногда встречались (достаточно редко - не более единиц раз в час). Мы их детектировали по установленному биту 14 при первом считывании данных цифрового канала в кадре.

В документации указано, что это - признак разрыва и начала нового непрерывного участка данных. Алгоритм установки этого бита там подробно не описан, но экспериментально было выяснено, что он устанавливается при первом считывании данных цифрового канала в кадре (а при последующих считываниях данных цифровых каналов в этом же кадре - уже не устанавливается).

Корреляций по времени между разрывами и появлением дубликатов данных на первый взгляд не видно, но обязательно проверим это более строго в ближайшее время.

Кстати, причины разрыва данных тоже не до конца понятны. E20-10 был единственным устройством, подключённым к USB-контроллеру (USB 3.0). Производительности компьютера также должно было хватать с большим запасом. Вполне возможно, что "узким местом" в данном случае является не компьютер, а сам E20-10, по какой-то причине не успевающий передавать все собранные данные. Но так или иначе наличие разрывов само по себе, с явно обозначенным местом разрыва нас вполне устраивает - логика эксперимента от этого не страдает. Плохо, когда наблюдается "подмена" одних (ожидаемых) данных другими, зарегистрированными ранее.

Алексей. Программно факт переполнения буфера FIFO E20-10 Вы отслеживали? В любом случае, Вам программно дана (понятна) эта возможность при работе через LCOMP? Если Вас наличие разрывов устраивает, то, с точки зрения логики системы, которую Вы эксплуатируете, - это нештатный режим работы данной системы сбора данных (пока не внедрён механизм контроля целостности данных). Штатый режим - это когда 0 разрывов и 0 потерь на протяжении сеанса работы.

Да, в lcomp такая возможность есть. Мы её тестировали - действительно, там признак переполнения появляется вскоре после того, как в потоке данных появляется кадр с установленным битом 14 в первом считывании в этом кадре данных цифрового канала.

Но длительной записи с отслеживанием переполнения у нас нет. В реальных экспериментах это не использовалось, т. к. таким образом место переполнения определяется только приблизительно, а по биту 14 его можно было определить точно (по крайней мере, как нам тогда казалось).

Это фундаментальная ошибка. Ваши данные нельзя назвать валидными, к сожалению. Мне жалко Ваших сил и времени.

Если Вас наличие разрывов устраивает, то, с точки зрения логики системы, которую Вы эксплуатируете, - это нештатный режим работы данной системы сбора данных (пока не внедрён механизм контроля целостности данных). Штатый режим - это когда 0 разрывов и 0 потерь на протяжении сеанса работы. Необходимым условием условием для штатного режима работы является отсутствие переполнений FIFO буфера.

Понятно, что без разрывов было бы намного лучше.

"Устраивает" - имеется ввиду, что эксперимент (достаточно сложный, дорогостоящий и длительный) планируется так, чтобы возникающие локальные по времени проблемы не сделали бы весь массив полученных данных бесполезным.

... Простите, и для этого дорогостоящего эксперимента Вы не контролировали время возникновения переполнения FIFO, чтобы можно было бы сразу гарантированно очистить невалидные куски данных (с запасом на глубину FIFO и запасом на асинхронность получения признака переполнения)?

В связи с вышесказанным, это может объясняться тем, что поскольку переполнения буфера FIFO, скорее всего, возникали, то возникала аварийная ситуация ( https://www.lcard.ru/download/e20_10_users_guide.pdf п. 5.2.4 "аварийной" откачки данных).  Это значит, система сбора данных эксплуатировалась в нештатном режиме.

Применяется параллельно несколько разных способов контроля на валидность промежуточных и окончательных данных. E20-10 - это не единственная измерительная система, участвующая в эксперименте. И возможные ошибки, связанные с E20-10 - не единственная причина возможной невалидности данных. Поэтому признак переполнение буфера и не использовался в качестве основного критерия качества данных.

Также мы полагали, что бит 14 - признак начала непрерывного участка данных - несёт в себе ту же информацию, что и признак переполнения буфера, но только с более точной привязкой по времени. Сейчас, когда стало понятно, что это не обязательно так, при первой же возможности добавим протоколирование признака переполнения.

Насколько я помню, этот бит был сделан для многократной внешней синхронизации старта сбора данных с заданным размером кадров, - только для того, чтобы в потоке видеть границы непрерывных участков, относящихся к разным моментам старта... В нештатном режиме работы (при переполнении FIFO) гарантировать непрерывность нельзя.

Но в нашей ситуации поток данных явно оказывается "рваным" как раз по этим битам, хотя внешняя синхронизация не используется. Таким образом, например, можно предположить несанкционированное задействование программного кода FPGA, ответственного за механизмы внешней синхронизации?