Minerva, Un SDR "cuda based"

Règles du forum
Cette section est dédié a vos projets, descriptions et demandes d'aide.
Merci de limiter le nombre de sujet par projets.
Lorsqu'un sujet deviens long vous pouvez éditer le premier message pour maintenir à jour le descriptif et garder en lisibilité
Avatar de l’utilisateur
marc
Electrolab::Membre
Messages : 840
Enregistré le : 14 mars 2017, 15:05

Minerva, Un SDR "cuda based"

Messagepar marc » 03 sept. 2017, 00:07

bonjour

Nous avions évoqué, lors de nos discussions, les travaux de Phil Harmann VK6PH, qui avait présenté un SDR format carte pci, dégagé de la "limitation" en termes de bande passante de la famille Hermes (384 kHz maxi par tranche de récepteur)

Je tiens le powerpoint de présentation de Minerva à la disposition de tous ceux qui le souhaiterait. De manière lapidaire, c'est un SDR 16 bits 160MSPS de type "direct fourier conversion" (tout le traitement numérique fait par le pc, avec l'assistance du traitement de GPU /cartes Cuda) , avec autant d'ADC en entrée que souhaités. Le transceiver est nativement prévu pour émettre avec un mécanisme EER (destruction/reconstion d'enveloppe)

En fait, les promesses sont bien plus alléchantes que supposées, comme vous pourrez en juger par la réponse de Phil. Seule ombre au tableau, c'est "schéma open, routage proprio, si vous voulez faire la même chose, appuyez vous le boulot". Car Abhi, le patron a déjà mis la main sur le design et en sort une version perso

ci après, mes questions et ses réponses. A mon humble avis, il y a plus de points positifs que négatifs

Hi Marc,

Thank you very much for your most welcome email. I have answered your questions below.

- Do you intend to spread/sell/distribute/diffuse Minerva to the Ham/hacker (or professional) community. Even bare pcb or gerber file would be really appreciate
- The PCB for Minerva is being layed out by Abhi from Apache Labs in India. Abhi will own the copyright for his PCB but I expect he will sell ready built Minerva boards as an Apache Labs product. If others wanted to design their own PCB then I don’t think this would be a problem.
- What will be the license status of such a development? Open or closed source/hardware? If Open, what kind of licence (BSD, MIT, gpl ?)
- The licence conditions for the PCB will be up to the person or company who designs the boards. I do not wish to lay out a PCB so this condition is fine with me. All my FPGA code will be open source under GPL. There is very little FPGA code, it is also very simple!
- What is the status and stage of development of the Minerva project (hardware and firmware/vhdl etc)
- Abhi designed a PCB for Minerva. Unfortunately there was an error in the PCIe interface which, since we are using a ball grid FPGA, we were not able to correct. Abhi has just sent me the Gerbers for a second version of the board and I hope to have a completed PCB in a few months time.
- I have written all the FPGA code necessary to test the Minerva board, both for transmit and receive. I also have used a DB4CGX15 evaluation board from Devboards in Germany to prove the PCIe interface works. By connecting an ADC to this board I was able to prove that DFC works but the sampling rate was limited to 73Msps due to the bandwidth of the PCIe bus. With the Minerva board we can sample at 122.88MHz or above.
- John Melton, G0ORX, wrote some code for this board when connected to an Nvidia TK1 board. His software made the TK1 appear to be a Hermes board on the network and worked very well.
- Whilst waiting for the Minerva board I have written FPGA code that can be run on a Hermes, Angelia or Orion board that provides raw ADC samples at 61.44Msps using raw Ethernet Frames over Gigabit Ethernet. Steve, AD0ES, has written code under Ubuntu that reads this data and provides multiple receivers. His Ubuntu code simulates multiple radios that comply with the new Protocol 2 and you can connect to them using Thetis. He is currently testing DFC for the Transmitter.
- You will find Steve’s work here – if is all open source http://ad0es.net/ngSDR/index.html. His web site is a little out of date but it will give you the general idea.
- You can email Steve if you are interested in his project – ad0es@ad0es.net
- Berndt, VK5ABN, is also working with Steve and myself and developing his own code.
- Do you intend to publish firmware code on Github of any other repository ?
- Yes, I will make all my code available on Github. It is very experimental at the moment and few people are testing it so that is why it is not public at the moment.
- What is the development stage of external frontends boards (ADC’s)
- I have many ideas but no hardware at the moment! I think using I2C to connect the front end modules will work well since others can use our boards. I think the Hermes-Lite group may also be interested in using this hardware. If you have hardware designers in your group who would like to assist then they would be very welcome to assist.

Please, excuse the rather rude formulation of my questions… let’s says this is the consequence of my curiosity and poor English language practice

No problem, I appreciate your interested in the project. Please don’t be concerned it there is a delay in me relying to any further emails. I am travelling a lot in September and October and may not have email access. In fact I am in holiday in your beautiful country from mid September for 3 weeks travelling from Paris to Nice on holiday.

73 Phil...VK6PH
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Minerva, Un SDR "cuda based"

Messagepar f4grx » 03 sept. 2017, 17:13

voici la seule chose que devrait faire un hermes et al pour moi:

Whilst waiting for the Minerva board I have written FPGA code that can be run on a Hermes, Angelia or Orion board that provides raw ADC samples at 61.44Msps using raw Ethernet Frames over Gigabit Ethernet.

Ainsi que des transactions SPI,I2C arbitraires.

point.

BCD? -> pcf8574.
Avatar de l’utilisateur
marc
Electrolab::Membre
Messages : 840
Enregistré le : 14 mars 2017, 15:05

Re: Minerva, Un SDR "cuda based"

Messagepar marc » 05 sept. 2017, 16:57

bcd peut prendre deux sens dans le monde hermes
- soit du véritable bcd sur un bus avec une progression logique, soit un mot de 7 bits dit "prise J6" destiné à commuter les filtres en sortie de la carte Pénélope (aka penny).
selon ce qu'a bidouillé l'utilisateur, et selon l'ordre de ses filtres, ça peut être un truc du genre
Xoooooo 160m
oXooooo 80m
ooXoooo 40m
oooXooo 30m
ooooXoo 20m
etc (en fait du pseudo décimal)
ou un pilotage de carte qui demande du véritable bcd
ooooooo
xoooooo
oxooooo
xxooooo
ooxoooo

voir du binaire réfléchi (code gray) de l'Aiken ou whatever

la "norme" J6 ou "Penny" est utilisée par le hermes lite, les 7 bits sont disponibles et peuvent piloter directement un driver de type ULN2803.
Sur le Red pitaya, elle est dispo à trois endroits différents : soit sur le connecteur E1, sur 4 broches (donc 4 bits) seulement, ce qui oblige les usagers à insérer un décodeur bcd/décimal entre le RP et les 8 ou 10 filtres à commuter. A noter qu'il y a un mot de données en émission, un autre en réception, ce qui permet de faire alternet plusieurs filtres ou combinaisons. Le troisième canal est le bus I2C (voir ci après)

la norme J15/J16,(aka Alex) est en revanche un train de bits sur un bus SPI, donc série. Décrit dans la doc alexiares....
Elle n'est pas gérée sur le hermes lite. Elle est dispo sur le Red Pitaya via un bus I2C. Il faut donc faire suivre ce bus par un décodeur I2C/décimal (pcf9555 par exemple). Le firmware du RP peut adresser deux décodeurs en parallèle, pilotés par deux adresses pour satisfaire à tous des conditions de Alexiares. Une troisième adresse I2C permet d'utiliser un décodeur pcf9555 en avec le train de bits penelope

bref, faut pas avoir 0,81 grammes dans le sang pour piger cette salade de commutation

faut-il préciser que sur carte hermes/angelia et suivantes, on a droit à fromage et dessert, c'est à dire Penelope en mode J6 et alex en mode J16

Marc
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Minerva, Un SDR "cuda based"

Messagepar f4grx » 25 sept. 2017, 11:01

sinon les GPU ca a pas l'air de casser 3 pattes a un hanneton, quand même...

https://drive.google.com/file/d/0B-CV_0 ... A0bkk/view

et c'est totalement normal vu que les GPUs cherchent a paralléliser les opérations alors que le SDR veut traiter du flux haut-débit temps réel...

si t'as de la diversity avec N>4 ou 8 récepteurs en parallèle OK mais pour du normal (et utilisable en pratique) => latences de malade

Dès que t'es obligé de copier des buffers entre la mémoire principale et la mémoire dédiée du GPU, c'est presque mort, parce qu'il vaut mieux faire les calculs directement sur place...

imagine que N vaut 1 million

avec un gpu, pour additionner deux buffers de N samples tu dois faire

Code : Tout sélectionner

memcpyRAMtoGPU(dest_a, a, N*sizeof(sample));
memcpyRAMtoGPU(dest_a, a, N*sizeof(sample));
run_gpu(add,dest_a,dest_b,dest_r);
memcpyGPUtoRAM(r, dest_r, N*sizeof(sample));


alors qu'avec un CPU tu fais DIRECTEMENT

Code : Tout sélectionner

for(i=0:i<N;i++) dest_r[i] = dest_a[i] + dest_b[i]


T'économises toutes les copies...

Donc ce qu'il faut c'est un ALU super rapide et efficace, ou du SIMD.

Parce qu'en fait oui, cet exemple est mauvais, car le GPU peut paralléliser les additions, car chaque addition s'applique a chaque élément sans dépendance. C'est le cas favorable selon la présentation GnuRadio

Dès que tu peux plus appliquer la même opération indépendamment a chaque sample... c'est mort, le CPU gagne.

ca inclut tout ce qui est intéressant, c'est a dire filtres... dont les samples dépendent des N précédents... causalité oblige!

Retourner vers « Les Projets »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité