Fantom schrieb:
> Witam
> Czy widzial ktos, jakies magiczne pudeleczko, gdzie z jednej strony
> mozna by mierzyc napiecie, a zdrugiej wpiac to w siec TCP/IP i je
> odczytywac ?
> Taka realizacja odczytu napiecia na odleglosc.
> Idea teoretycznie prosta do zrealizowania, ale chyba tak niszowy to
> produkty by byl, ze watpie iz istnieje.

Muszę sprawdzić w domu. Mam zrobione międzymordzie kupione jako kit z 8
kanałami we-wy TTL. O ile mnie skleroza nie myli, to ma to jeszcze 4
kanały 12 bit ADC. Ewentualnie podłączyć przez te TTLki jakiś seryjny
ADC z lepszą rozdzielczością lub multimetr z wyjściem RS.
Gotowce widziałem kiedyś na targach w Hanowerze (do zamontowania na
szynie), ale cena była (wtedy) zaporowa (coś w okolicach 1kEUR), więc
raczej bez sensu.
Można też wyrzeźbić coś podobnego używając routera. Coponiektóre mają
RS232 na burcie, tylko nie jest ono wyprowadzone na zewnątrz.

Waldek

do góry

Waldemar Krzok pisze:

> Można też wyrzeźbić coś podobnego używając routera. Coponiektóre mają
> RS232 na burcie, tylko nie jest ono wyprowadzone na zewnątrz.

Był taki projekt, w którym w małym AVR zmieścił się nadajnik pakietów
UDP. Zero odbioru i potwierdzenia ale całość to tylko atmega i garść
oporków. Jeśli jest jeszcze miejsce we flashu to można dodać obsługę ADC
i wynik wysyłać po UDP.

--
Filip.

do góry

Michal Smolnik wrote:
>>> Sprzęt jest gotowy, z papierami i w ciągłej produkcji. Mogę go kupić
>>> od mojego klienta i wlać inny soft.
>> Czy wtedy papiery będą ważne?
> Tak.

Jeśli "papiery" to CE to mam taką wątpliwość:

Produkuje generator ktory podczas pomiarów na CE nic nie generuje.
Dostaje papier na CE. Ładuje inny soft, który sieje tak, ze zakłuca
staruszkom w okolicy Radyjo. Dalej mam CE ?

Innymi słowy: czy wymiana firmware wymaga ponownego przebadania,
przynajmniej w teorii?

do góry

Filip Ozimek wrote:
> Był taki projekt, w którym w małym AVR zmieścił się nadajnik
> pakietów UDP.

Ale miał wadę. Zawartość pakietow byla ustalana compile-time. Moze ale
nie musi być to upierdliwe.

do góry

Sebastian Biały pisze:
> Filip Ozimek wrote:
>> Był taki projekt, w którym w małym AVR zmieścił się nadajnik
>> pakietów UDP.
>
> Ale miał wadę. Zawartość pakietow byla ustalana compile-time. Moze ale
> nie musi być to upierdliwe.

A to kicha. Zawsze można napisać kod który sam siebie będzie zmieniał -
nie wiem tylko czy w AVR kod ma dostęp do pamięci w której siedzi.

--
Filip.

do góry

Filip Ozimek wrote:
>> Ale miał wadę. Zawartość pakietow byla ustalana compile-time. Moze ale
>> nie musi być to upierdliwe.

> A to kicha. Zawsze można napisać kod który sam siebie będzie
> zmieniał - nie wiem tylko czy w AVR kod ma dostęp do pamięci w której
> siedzi.

Musiał by sie flashować - AVR to harvard i nie da sie wykonywac kodu z
RAM. A Ethernet jest na kompletnej granicy osiąganej przez kod
generowany w AVR i nie mozna mieć żadnej logiki, to jedna z drugą
instrukcja machania pinem na porcie.

Swoją drogą autor UDP na AVR radził sobie tak, ze nie zawartość pakietu
miała znaczenie, tylko miał dwa pakiety wysyłane w odpowiedniej
kolejności oznaczajace "1" i "0" które po stronie odbiornika były
skladane w bajty i całe messages. Dalo sie więc wyslać dowolna
informacje ale rozbitą na kawałki po jedym bicie per ramka UDP.

do góry

W dniu 2010-01-19 23:47, Sebastian Biały pisze:

> Innymi słowy: czy wymiana firmware wymaga ponownego przebadania,
> przynajmniej w teorii?

Jeżeli po zmianach w oprogramowaniu urządzenie będzie spełniać wymogi
norm określanych przez CE... to nie musisz nic badać.

Czujesz bluesa? :-)

pzdr
mk

do góry

Sebastian Biały pisze:
> Jeśli "papiery" to CE to mam taką wątpliwość:
>
> Produkuje generator ktory podczas pomiarów na CE nic nie generuje.
> Dostaje papier na CE. Ładuje inny soft, który sieje tak, ze zakłuca
> staruszkom w okolicy Radyjo. Dalej mam CE ?
>
> Innymi słowy: czy wymiana firmware wymaga ponownego przebadania,
> przynajmniej w teorii?

Deklaracja zgodności CE jest deklaracją _producenta_, czyli w tym
przypadku moją.
W przypadku urządzenia, które podlega dyrektywie EMC to ja muszę
podeprzeć się badaniami żeby spać spokojnie a klientowi nie są one
potrzebne.
Jeżeli skonstruowałem urządzenie, które badane z softem robiącym mniej
więcej to samo (komunikacja RS232 i Eth) przeszło badania (z resztą z
wynikiem bardzo ładnym mimo że ma niekorzystne z punktu widzenia EMC
ułożenie płytek i plastikową obudowę) i zmieniam soft tak, że działanie
programu z punktu widzenia emisji i odporności będzie identyczne - _ja_
mogę nadal ze spokojem deklarować spełnienie norm zharmonizowanych.

Do badań trzeba po prostu podejść uczciwie i dla własnego spokoju badać
urządzenie takie jak pójdzie do klientów.
Jeśli UKE kiedyś będzie chciał sprawdzić Twój produkt, weźmie przecież
sztukę z rynku a nie wzorcowy egzemplarz badany przez Ciebie.

CE to nie jest dopuszczenie typu, jak np. na rynku kolejowym, gdzie
każda zmiana w produkcie to nowa ścieżka wydeptana na korytarzach
instytutów (badania i opinie) i państwowego regulatora (konsumpcja
powyższych papierów) i ubytek co najmniej kilkunastu tysięcy z kieszeni.

Pozdrawiam,
Michał

do góry

Michal Smolnik wrote:
>> Innymi słowy: czy wymiana firmware wymaga ponownego przebadania,
>> przynajmniej w teorii?
> Deklaracja zgodności CE jest deklaracją _producenta_, czyli w tym
> przypadku moją.

Oczywiscie. Deklarujesz: moje urządzenie w wersji firmware v1.0 przeszło
badania. Teraz jest v2.0. Papiery z badań sa na v1.0. To nieuczciwe i
ryzykowne (dla ciebie i klienta).

> W przypadku urządzenia, które podlega dyrektywie EMC to ja muszę
> podeprzeć się badaniami żeby spać spokojnie a klientowi nie są one
> potrzebne.

Gdyby klientowi nie byly potrzebne to nie bylo by znaczka CE na
obudowie. A jest. Co prawda fascynujących tabelek z kupą liczba nie
widać, ale widać że producent odważył się nadać CE więc miał do tego
podstawy. Niestety zgodnośc z CE wyssał z palca, bo badał tylko na
starym firmware.

> zmieniam soft tak, że działanie
> programu z punktu widzenia emisji i odporności będzie identyczne - _ja_
> mogę nadal ze spokojem deklarować spełnienie norm zharmonizowanych.

No właśnie nie jestem pewny. Co jeśli masz buga w sofcie który objawia
się nie spelnianiem norm?

> Do badań trzeba po prostu podejść uczciwie i dla własnego spokoju badać
> urządzenie takie jak pójdzie do klientów.

O tym mówię. Wymiana firmware bez względu na to jak mała poprawkę robisz
nie jest uczciwa do końca. "Wszyscy tak robią" ale może nie robią
dobrze. Choć doskonale sobie zdaje sprawę, że robienie po raz kolejny
badania tego samego hardware jest z perspektywy utraty zarobku mało
sensowne.

PS. Ja się nie czepiam. Jestem ciekaw na ile firmware stanowi część
urządzenia podlegającą badaniu i na ile jego zmiana może być traktowana
przez producenta jak nie istotna poprawka.

do góry

Żeby nie było porozumień zakładam, że cały czas mówimy o najprostszym
przypadku urządzenia podlegającego EMC, a nie podlegającego RTTE i LVD i
innym branżowym dopuszczeniom.

Sebastian Biały pisze:
>>> Innymi słowy: czy wymiana firmware wymaga ponownego przebadania,
>>> przynajmniej w teorii?
>> Deklaracja zgodności CE jest deklaracją _producenta_, czyli w tym
>> przypadku moją.
>
> Oczywiscie. Deklarujesz: moje urządzenie w wersji firmware v1.0 przeszło
> badania. Teraz jest v2.0. Papiery z badań sa na v1.0. To nieuczciwe i
> ryzykowne (dla ciebie i klienta).

Zgodnie z przepisami deklaruję: "Moje urządzenie jest zgodne z dyrektywą
EMC bo spełnia zharmonizowane z nią normy ble ble ble."
Tylko tyle. Wykonanie badań nie pozwala na przerzucenie
odpowiedzialności na labo (nawet jeśli to jest jednostka notyfikowana).

>> W przypadku urządzenia, które podlega dyrektywie EMC to ja muszę
>> podeprzeć się badaniami żeby spać spokojnie a klientowi nie są one
>> potrzebne.
>
> Gdyby klientowi nie byly potrzebne to nie bylo by znaczka CE na
> obudowie. A jest. Co prawda fascynujących tabelek z kupą liczba nie
> widać, ale widać że producent odważył się nadać CE więc miał do tego
> podstawy. Niestety zgodnośc z CE wyssał z palca, bo badał tylko na
> starym firmware.

Znaczek CE w świetle wszystkich z nim związanych dyrektyw oznacza "jest
zgodne z odpowiednimi dla tego przedmiotu dyrektywami" i nie implikuje
że zostały przeprowadzone badania (mogą rzecz jasna wynikać z dyrektyw).

>> zmieniam soft tak, że działanie programu z punktu widzenia emisji i
>> odporności będzie identyczne - _ja_ mogę nadal ze spokojem deklarować
>> spełnienie norm zharmonizowanych.
>
> No właśnie nie jestem pewny. Co jeśli masz buga w sofcie który objawia
> się nie spelnianiem norm?

Żadne badania nie są wystarczającym dupochronem - to można by wpisać
jako motto dyrektyw tzw. "nowego podejścia".
Bo można gdybać - a co jeśli jest wyciek pamięci i po przepracowaniu 24h
program idzie w krzaki i zaczyna emitować śmieci? Czy badania w komorze
należy przeprowadzić przez 24h?

Powtórzę. W założonym na wstępie przypadku (który dotyczy akurat
urządzenia dla którego zaczęła się dyskusja) badania są dla mnie.
Jeżeli jako konstruktor wiem:
1) urządzenie składa się z interfejsu RS232 na MAX3232, procesora
armopodobnego gadającego z eth przez normalne gotowe PHY i kawałka
układów zasilających (nie sterowanych przez procesor)
2) jakiekolwiek zachowanie procesora i programu w jakiejkolwiek wersji w
takiej konfiguracji sprzętowej nie spowoduje emisji przekraczającej
normy a w urządzeniu nie ma sprzętu, którego odporność na zaburzenie
będzie zależała od wlanego softu
W takiej sytuacji, jednocześnie jako osoba reprezentująca firmę (taką
mam teraz skalę działalności) deklaruję zgodność urządzenia, nie
precyzując wersji firmware.
Oczywiście inaczej bym postąpił nie mając powyższej pewności.

AFAIR w wytycznych do badań EMC np. komputerów PC założenie jest aby na
komputerze uruchomiona była aplikacja w miarę możliwości maksymalnie
wykorzystująca zasoby systemu.
Przypadkiem widziałem badania takiego komputera z handlu w
najważniejszym (w sensie znaku CE) polskim laboratorium - CLBT - na
komputerze był pulpit Windows...

>> Do badań trzeba po prostu podejść uczciwie i dla własnego spokoju
>> badać urządzenie takie jak pójdzie do klientów.
>
> O tym mówię. Wymiana firmware bez względu na to jak mała poprawkę robisz
> nie jest uczciwa do końca. "Wszyscy tak robią" ale może nie robią
> dobrze. Choć doskonale sobie zdaje sprawę, że robienie po raz kolejny
> badania tego samego hardware jest z perspektywy utraty zarobku mało
> sensowne.

Według mojej wiedzy w założonym na początku przypadku decyzja czy
przeprowadzać badania należy do wprowadzającego do obrotu - nie ma
obowiązku przeprowadzania badań za każdym razem, można również
przeprowadzić badania uproszczone - fragmentaryczne.

> PS. Ja się nie czepiam. Jestem ciekaw na ile firmware stanowi część
> urządzenia podlegającą badaniu i na ile jego zmiana może być traktowana
> przez producenta jak nie istotna poprawka.

Powiem ogólnie - dyrektywy "nowego podejścia" są kiepsko napisane -
wiele w nich nieścisłości a osoby, które powinny być w nich zorientowane
wiedzą zwykle jeszcze mniej od nas.
Pewne ścieżki już wydeptałem w praktyce, ale to co utrudnia działanie i
rozwój produktów, to głównie brak jednoznacznych i prostych zasad - dla
wszystkich.

Pozdrawiam,
Michał

do góry