Beiträge von DL8MBY

Hallo Uwe,

neues Problem

root@red-pitaya:/home/sdr/iqgen2# ./iq 10.0e6 +900 +0.0 +0.0 <= Bild #1 Kreis ok
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 +900 +0.0 +0.0 dito
root@red-pitaya:/home/sdr/iqgen2# ./iq 5.0e6 +900 +0.0 +0.0 dito
root@red-pitaya:/home/sdr/iqgen2# ./iq 8.0e6 +900 +0.0 +0.0 dito
root@red-pitaya:/home/sdr/iqgen2# ./iq 9.0e6 +900 +0.0 +0.0 dito
root@red-pitaya:/home/sdr/iqgen2# ./iq 10.0e6 +900 +0.0 +0.0 <= Bild #2 Kreis verformt
root@red-pitaya:/home/sdr/iqgen2# ./iq 12.0e6 +900 +0.0 +0.0
root@red-pitaya:/home/sdr/iqgen2# ./iq 11.0e6 +900 +0.0 +0.0
root@red-pitaya:/home/sdr/iqgen2# ./iq 15.0e6 +900 +0.0 +0.0 <= Bild #3 kreis verformt und größer!

Ab zehn MHz wird der Kreis Unsymetrisch - (keine Elipse sondern ein Tropfen!)
Zudem steigt der Pegel an, verbeulter Kreis wird größer

Siehe Anhang

Markus

Anbei noch meine Calibrationskonstanten aus dem EEPROM:

root@red-pitaya:/home/sdr/iqgen2# calib -r -v
FE_CH1_FS_G_HI = 45870551
FE_CH2_FS_G_HI = 45870551
FE_CH1_FS_G_LO = 1016267064
FE_CH2_FS_G_LO = 1016267064
FE_CH1_DC_offs = 78
FE_CH2_DC_offs = 25
BE_CH1_FS = 42755331
BE_CH2_FS = 42755331
BE_CH1_DC_offs = -150
BE_CH2_DC_offs = -150

Hallo Uwe,

kann bestätigen, dass der neue Code immer einen Kreis zeichnet.

root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 -900 +0.0 +0.0 <==KreIs
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 +900 +0.0 +0.0 <==KreIs
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 +450 +0.0 +0.0
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 +1350 +0.0 +0.0
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 -1350 +0.0 +0.0
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 -450 +0.0 +0.0
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 -900 +0.0 +0.0 <==KreIs
root@red-pitaya:/home/sdr/iqgen2# ./iq 1.0e6 +900 +0.0 +0.0 <==KreIs

Glückwunsch.

Jetzt werde ich den DC-Offset bestimmen.

Markus

Hallo Uwe,

möglicherweise ist dies nicht der Richtige Ort diese Frage zu stellen.
Ich versuche es trotzdem:

Sollte es in der fpga_awg.h statt

typedef struct awg_reg_t {
/** @brief Offset 0x00 - State machine configuration
*
* State machine configuration register (offset 0x00):
* bits [31:24] - Reserved
* bit [ 23] - Channel B output set to 0
* bit [ 22] - Channel B state machine reset
* bit [ 21] - Channel B set one time trigger
* bit [ 20] - Channel B state machine wrap pointer
* bits [19:16] - Channel B trigger selector
* bits [15: 8] - Reserved
* bit [ 7] - Channel B output set to 0
* bit [ 6] - Channel B state machine reset
* bit [ 5] - Channel B set one time trigger
* bit [ 4] - Channel B state machine wrap pointer
* bits [ 3: 0] - Channel B trigger selector
*
*/

nicht

typedef struct awg_reg_t {
/** @brief Offset 0x00 - State machine configuration
*
* State machine configuration register (offset 0x00):
* bits [31:24] - Reserved
* bit [ 23] - Channel B output set to 0
* bit [ 22] - Channel B state machine reset
* bit [ 21] - Channel B set one time trigger
* bit [ 20] - Channel B state machine wrap pointer
* bits [19:16] - Channel B trigger selector
* bits [15: 8] - Reserved
* bit [ 7] - Channel A output set to 0
* bit [ 6] - Channel A state machine reset
* bit [ 5] - Channel A set one time trigger
* bit [ 4] - Channel A state machine wrap pointer
* bits [ 3: 0] - Channel A trigger selector
*
*/

oder umgekehrt

typedef struct awg_reg_t {
/** @brief Offset 0x00 - State machine configuration
*
* State machine configuration register (offset 0x00):
* bits [31:24] - Reserved
* bit [ 23] - Channel A output set to 0
* bit [ 22] - Channel A state machine reset
* bit [ 21] - Channel A set one time trigger
* bit [ 20] - Channel A state machine wrap pointer
* bits [19:16] - Channel B trigger selector
* bits [15: 8] - Reserved
* bit [ 7] - Channel B output set to 0
* bit [ 6] - Channel B state machine reset
* bit [ 5] - Channel B set one time trigger
* bit [ 4] - Channel B state machine wrap pointer
* bits [ 3: 0] - Channel B trigger selector
*
*/

heisen?

Markus

HAllo Uwe,

danke für Deine ausführiche Antwort.

Zu der Konstantenänderung (auf die schnelle klappt es leider nicht)

"die Konstante auf 0x410041"

musst Du mir bitte noch sagen wo ich diese ändern soll.

Es gibt ja zwei Stellen, wo sie gesetzt werden:

Zeile 123: g_awg_reg->state_machine_conf = 0x000041;

und

Zeile 145: g_awg_reg->state_machine_conf = 0x110011;

oder sollen beide auf den o.g. Wert geändert werden?

Markus

Hallo OMs,

die ersten Schritte sind wie immer erwas Mühsam.

Verstehe ich das soweit richtig, dass der RP im FPGA bereits vorkonfigurierte
Funktionsblöcke beinhaltet, auf die man dan z.B. über Libs / Header-Files
zugreifen kann.

z.B. Arbitrary Waveform Generator (AWG) FPGA controller als Funktionsblock
kann über die Files fpga_awg.h / fpga_awg.c angesprochen werden.

Solange der FPGA nicht neu mit Strukturanweisungen gefüllt wird, wozu man ja die
Xilinx-Tools braucht, kann man auf diese vorkonfigurierten Strukturen, die im
Auslieferungszustand vorhanden sing, zugreifen.

Für heute genug gespielt - Jetzt gehts ins Bett

Morgen ist ja auch noch ein Tag.

Markus

Hallo Uwe,

ich schon wieder,

habe halt RP Blut geleckt

ist das der Code in dem Du eine LTU für den Sin/Cos aufbaust
um sie dann an den Kanal A/B zu schicken?

for(uint32_t i = 0; i < n; i++) {
data = round(amp1 * cos(2*M_PI*(double)i/(double)n));
if (data < 0) {
data += (1 << 14);
}

g_awg_cha_mem[i] = data;

data = round(amp2 * cos(2*M_PI*(double)((phase_offset + i) % n)/(double)n));
if (data < 0) {
data += (1 << 14);
}

g_awg_chb_mem[i] = data;

Anscheinend braucht man diese _agw_ Funktionen um mit dem Konfiguriertem FPGA zu kommunizieren.

Wo kann man sich über die Aufrufe

g_awg_reg->state_machine_conf = 0x000041;

und

g_awg_reg->state_machine_conf = 0x110011;

schlau machen, wie sind die Flags zu intepretieren.

Markus

Konnte meine Frage selbst beantworten:

uint32_t state_machine_conf;
/** @brief Offset 0x04 - Channel A amplitude scale and offset
*
* Channel A amplitude scale and offset register (offset 0x04) used to set the
* amplitude and scale of output signal: out = (data * scale)/0x2000 + offset
* bits [31:30] - Reserved
* bits [29:16] - Amplitude offset
* bits [15:14] - Reserved
* bits [13: 0] - Amplitude scale (0x2000 == multiply by 1, unsigned)
*/

aus fpga_awg.h

Hallo Uwe,

einen habe ich noch

Ich verstehe folgenden Zusammenhang nicht:
In der ersten if-Anweisung wird dafür gesorgt, dass der
Phasenparameter zwischen -1799 und + 1800 liegt,
sonst wird der Programmablauf unterbrohen.
In der Zugehörigen else-Anweisung wird der Phasenwert
Modulo 3600 geteilt, aber der Rest ist ja immer gleich dem
ursprünglichem Wert des Phasenparameters, da dieser
doch immer kleiner 1800 ist.

Kannst Du mir erklären was Du mit der Modulo 3600 Division
bezweckst. Irgend wie stehe ich auf dem Schlauch, was diese
Codesequenz angeht.

/* Phase Offset */
int32_t phase_offset = atoi(argv[2]);
if ((phase_offset < -1799) (phase_offset > 1800)) { <============= 1.
fprintf(stderr, "Invalid phase shift: %s\n", argv[2]);
usage();

return -1;

} else {
phase_offset = phase_offset % 3600; <============== 2.
if (phase_offset < 0) {
phase_offset += 3600;
}

/* scale it to match AWG buffer length */
phase_offset = n * phase_offset / 3600;

}

Danke für Deine Mühe schon mal im Vorraus.

Gruß
Markus

Hallo Uwe,

wie sind die Werte

const int dcoffs = -155;
const int trans0 = 30;
const int trans1 = 300;

aus der iq.c Datei zu verstehen.

Hast Du diese empirisch ermittelt für Deinen RP?

Bei mir liefert ein erneuter Aufruf mit +950 oder -850 als Parameter
für die Phase einen kreisrunden Kreis.

Sieht aus, alls wenn nach dem erstmalliegem Start, irgend ein Offset von
50 in Phasen Buffer dazukommen würde.

Gruß
Markus
DL8MBY

Hallo Wolfgang, Uwe und OMs,

Ich habe einige Sereenshots zum IQ-Gen vom Uwe angehängt.
Mir ist aufgefallen, dass ein XY-Darstellung nicht immer den selben
Wert liefert.

z.B.

nach dem Einschalten des RP

Bild #1: (Punkt in der Bildmitte, da kein Signal am DAC)

Bild #2: (schöner Kreis bei dem Aufruf von iqgen mit folgenden Parametern)

./iq 1.0e6 -900 +0.0 +0.0

Bild #3: (Nun Phase nicht um 90° sondern um 45° verschoben - Aufruf von iqgen mit folgenden Parametern)

./iq 1.0e6 -450 +0.0 +0.0

Bild #4: (nun wieder den verhergehenden Zustand wieder herstellen d.h. Phase um 90° verschoben)

./iq 1.0e6 -900 +0.0 +0.0

Leider liefert diese erneute Einstellung keinen unverzehrten Kreis mehr.

Was meinst Du Uwe dazu?

Wolfgang,

um eine Partition einer SD-Karte unter Linux zu vergrößern, gehst Du bitte wie folgt vor.

Partitionstabelle des Karten-Image mit fdisk -l /dev/<SD-Karten-Name> betrachten

Bei mir ist <SD-Karten-Name> z.B. mmcblck0, könnte aber auch sdb oder sdc sein,
je nach Anzahl der verbauten Disks im Rechner.

Hilfreich ist der Befehl lsscsi und auch lsusb, der angeschlossene Devices zeigt.

Bei meinem RP liefert fdisk -l die folgende Ausgabe

root@red-pitaya:/home/sdr/iqgen# fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004085a

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 30719 22528 11M e W95 FAT16 (LBA)
/dev/mmcblk0p2 30720 31116287 31085568 14.8G 83 Linux

Dies ist aber bereits die Ausgabe für meine vergrößerte Partition mmcblk0p2.

Wenn Du das Original-Image auf die SD-Karte mit dd übertragen hast und der Aufbau
wie folgt ist:

/dev/mmcblk0p1 8192 30719 22528 11M e W95 FAT16 (LBA)
/dev/mmcblk0p2 30720 XXXXXX YYYYYY ZZ.8G 83 Linux

und du willst die letzte Partition vergroßern, so musst Du:

1) mit fdisk die Partition #2 löschen
2) mit fdisk die Partition #2 neu Anlegen (primär Partition)
2a) als Startwert der Partition #2 den Endwert der Partition #1 + 1 angeben
hier ist es der Wert 30720 = 30719 + 1
2b) den Endwert der Partition #2 als letzten größtmöglichen Wert der SD-Karte nehmen.
Diesen Wert ermittelt man am besten vor dem Draufspielen des Images mit fdisk -l /dev/...
3) die neu angelegte Partition durch Speichern permanent machen.

Die einzelnen Kommandos lauten unter fdisk:

1) fdisk /dev/mmcblk0 (diesmal ohne -l für list d.h. nur ansehen und nichts modifizieren)
2) <p> <== Partitionstabelle erneut zeigen
3) <d> Partition
3) <2> #2 löschen
4) <n> neue partition anlegen
5) <p> eine primäre Partition als Type wehlen
6) ... Start und Stop Block setzen
7) <p> Partitionstabelle nochmal ansehen und auf Fehler (Überlappungen) prüfen
8a) <q> quit, ohne speichern raus - wenn nötig
8b) <w> veränderte Partitionstabelle schreiben.
8c) <q> program verlassen.

Hoffe keinen Schritt vergessen zu haben - war aus dem Gedächtnis.

Bevor man Punkt 1 - 8 durchführt muss man sicherstellen, das beim Einstecken der
SD-Karte diese nicht sofort vom System eingebunden wurde (mount Befehl)
Falls man einen Eintrag wie

/dev/mmcblk0p1 on xyz
/dev/mmcblk0p2 on xyz

findet,
diesen mit umount /dev/mmcblk0p1 oder/und umount /dev/mmcblk0p2 aushängen.

Alles als root user!!!

Jetzt muss man nur noch das Filesystem der zweiten Partition mit fsck analysieren

fsck -f /dev/mmcblk0p2

und dann den Resize-Vorgang anstoßen:

resize2fs /dev/mmcblk0p2

geschafft - und ich auch

Gruß
Markus

Hallo Uwe,

ich dachte Du meinst die Eingangsabtastung, aber nach Deinem Bild zu urleilen sind es die
Ausgangssignale die der RP erzeugt, die nicht sauber sind - richtig?

Gruß
Markus
DL8MBY

Hallo Uwe,

ich habe noch ein Zweiton-Signal, vom Notebook, siehe Bild, an Eingang 1 angelegt.
800Hz + 1200Hz.

Gruß
Markus

PS.:

Bei mir sind es ebenfalls 75°C

root@red-pitaya:~# monitor -ams
#ID Desc Raw Val
0 Temp(0C-85C) b07 74.279
1 AI0(0-3.5V) a 0.017
2 AI1(0-3.5V) 12 0.031
3 AI2(0-3.5V) 9 0.015
4 AI3(0-3.5V) a 0.017
5 AI4(5V0) 67f 4.964
6 VCCPINT(1V0) 56a 1.015
7 VCCPAUX(1V8) 9b3 1.819
8 VCCBRAM(1V0) 56a 1.015
9 VCCINT(1V0) 56c 1.017
10 VCCAUX(1V8) 9ad 1.815
11 VCCDDR(1V5) 802 1.502
12 AO0(0-1.8V) f0000 0.173
13 AO1(0-1.8V) 4e0000 0.900
14 AO2(0-1.8V) 750000 1.350
15 AO3(0-1.8V) 9c0000 1.800

Hallo Uwe,

richtig, habe noch keinen Lüfter dran.
Mir ist aber auch aufgefallen, dass der Chip recht heiß wird.

Ich sätze aber dass man den Lüfter extern versorgen muss
(12V) um keine Störungen Onboard einzustrahlen.

Alternativ könnte man einen höheren Kühlkörper nehmen.
Scheint ein standart Fabrikat zu sein.

Muss mal meine alten Mainboards und Graphikkarten durchsehen,
ob da nicht ein ähnlicher verbaut ist.

Da der FA-VA3 erst ab 50KHz läuft, habe ich Dir nur ein Abbild
von dieser Frequenz angehängt.

Wie schon nachgefragt, sind auch in meiner Darstellung des Spektrums
störende Linien zu sehen.

Muss mal in der Arbeit am Spektrumanalyzer nachmessen, ob der VA oder der
RP diese Linien erzeugt.

Markus

Hallo OMs,

ein kleiner Nachtrag zum RP.

Benutzung des Webinterfaces ermöglicht z.B. die Auswahl eines
Spectrumanalyzers - was Ihr bestimmt schon bereits kennt.

Ich habe diesem Eingang #1 zweimal das Signal (20MHz)
eines FA-VA3 angeboten. Einmal mit vorgeschaltetem 10dB
ATT und einmal direkt 1:1 - so zum testen.

Siehe die angehängten Jpg-Files.

Jetzt wird aber ausgiebig gespielt

Gruß
Markus

War natürlich Schmart mit den 10dB ATT - waren 30dB Dämpfung!

Hallo Uwe,

die erstinstallation war soweit erfolgreich. 20Min. samt Download vom Image.

ich habe bei mir die IP statisch eingestellt, damit ich keinen DHCP server aufsetzen muss.

Geht durch Modifikation der eth0 Datei im Verzeichnis

/etc/network/interfaces.d auf der zweiten Partition der SD-Karte /dev/mmcblk0p2

Ersetzt wurde erste und einzige Zeile

iface eth0 inet dhcp

durch

z.B.

auto eth0
iface eth0 inet static
address 192.0.1.7
netmask 255.255.255.0
gateway 192.0.1.254

Dies kann man sofort nach der erstellung des SD-Images machen, noch bevor
man die SD-Karte in den RP steckt. Dadurch ist der RP sofort auf der gesetzten
IP via ssh ansprechbar:

ssh root@192.0.1.7 (pw changeme)

Anbei meine Status-Infos vom laufenden Debian auf dem RP.

root@red-pitaya:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 503M 14G 4% /
devtmpfs 226M 0 226M 0% /dev
tmpfs 234M 0 234M 0% /dev/shm
tmpfs 234M 4.3M 230M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 234M 0 234M 0% /sys/fs/cgroup
/dev/mmcblk0p1 11M 6.3M 4.8M 57% /boot
root@red-pitaya:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

processor : 1
model name : ARMv7 Processor rev 0 (v7l)
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Xilinx Zynq Platform
Revision : 0003
Serial : 0000000000000000

Ich hoffe die Infos helfen weiteren RP Enthusiasten, wie mir die Infos von
Uwe geholfen haben und binnen Minuten zu einem lauffähigem System geführt
haben.

Nochmals verbindlichten Dank Uwe!

vy73
Markus
DL8MBY

Danke Uwe,

werde gleich nach dem QRL mein Glück mit dem RP ausprobieren.

vy73
Markus
DL8MBY

Hallo Uwe,
hallo OMs,

halte gerade auch die schnuckelige RP Platine in meinen händen.
Kann mir einer auf die Schnelle sagen, wie man den Code compiliert
und in den Arm lädt.

Grundlagen in C und Linux sind vorhanden, es geht mir rein um die RP
spezifischen Tools und ihr Handling.

Wollte mir das durchforsten der Doku sparen und ein Erfolgserlebnis
sehen, bevor ich mich mehr in die Tiefe der Materie einarbeite.

Als bitte um Nachsicht.

Danke!

Markus
DL8MBY

Hallo Uli,

danke für den Tipp.

Schönes Tool. Läuft auf Anhieb in Linux unter wine,
siehe Anhang.

Schönen Dank!

vy73
Markus
DL8MBY

Hallo OM's,

war am WE unterwegs, konnte mich deshalb an der regen Diskission nicht beteiligen.

Zu den Messungen ist folgendes zu sagen:

Es wurde am TX der konstante Träger (Mode CM) ohne Tastung am 30dB Dämpfungsglied
mit einem Advantest 3131 Spektrumanalyzer gemessen.

Dabei stellte sich heraus, dass die Oberwellen meist 53dB unterhalb des Trägers waren.
Ausnahme 10 und 14 MHz Band 43dB und 48 dB Abstand zum Träger.

Bei Modulation des Trägers mit Fonie aber auch CW-Tastung entstanden die bereits erwähnten
Nebenaussendungen, die relativ breitbandig (+- 50 kHz) sind und bis auf 30dB in der Spitze an
den Träger herranreichen.

Wir haben aus Zeitgründen und Mangels eines USB-Sticks keine Screendumps gemacht, werden
dies aber noch nachholen.

Es wurde keine Zweitonmessung weder am RX noch am TX durchgeführt - Dazu suchen wir noch
eine Möglichkeit im OV od. bei befreundeten OMs. Möglicherweise kann Norbert - DJ9RB - dies
demnächst untersuchen.

Beim RX haben wir nicht nur S9 zu S2 Signale im 4kHz Abstand verglichen, sondern auch S9+40
mit S2 - der Abstand betrug 14kHz. Gemessen wurde der Pegel des leisen Signals mit mV-Meter
und Oszi beim Ein-und Abschalten des starken Störträgers.

Zuvor hatten wir noch, wie bereits beschrieben, die Empfindlichkeiten mit und ohne PRE und ATT
gemessen. (Siehe meinen erster Beitrag.)

Wie bereits erwähnt, wollen wir noch Messungen bei externer Tastung (Palm-Keyer) am Träger machen,
um zu sehen ob dort auch die Nebenaussendungen erkennbar sind.
Unser Verdacht ist nämlich, dass der uC wohlmöglich den TX zu steil Tastet und ein RC Glied an der
Nahtstelle die Probleme beheben würde.

Werde im Urlaub, mitte August, mehr Zeit zum Spielen mit dem Gerät haben und berichten.

vy73
Markus
DL8MBY

Hallo Peter, hallo OMs,

gemeint war, dass der TRX z.Z. nicht zur Ansteuerung einer PA geeignet ist, die z.B. 750W HF macht.
Rudi wollte sich sein solches Gerät zulegen, um in seinem Shack etwas Platz zu schaffen.
Davon habe ich Ihm nach jetzigem Erkenntnisstand abgeraten, wegen der besagten Messwerte.
Auf der HAM-Radio, hatten wir diesen Messmöglichkeit nicht, sondern erst im QRL.
Wir konnten das Gerät nur an der Logperiodic und der Vertikal nur subjektiv und mittels Web-SDR
testen.

Da der reine Träger sehr gut aussieht, glaube ich nicht, dass es an der Hardware liegt, sondern an der
Firmware - meine persönliche Meinung.

Ich habe gerade mit den mir zur Verfügung stehenden Messmöglichkeiten am QTH die Filter des Gerätes
durchgesweept und hänge die Screenshots an.

Gemessen habe ich im 40m Band.
RX ohne PRE und ATT.
Generatorsignal am RX (FA-NWT) mit eingeschaltetem Dämpfungsglied (44dB)
Messeingang mit 30dB auf den der Audioausgang des RX gelegt ist (halbe Lautstärke)
AGC aus.

Werte wurden so gewählt, damit eine gute rauschfreie Grundlinie entsteht.

Weitere Messungen folgen.

Ich hoffe mich nun etwas klarer ausgedrückt zu haben.

vy73
Markus
DL8MBY

Hallo Markus,

bin ganz Deiner Meinung, zumal ja vieles an Technik aus dem Smartphonebereich verwendet werden kann.

Leider hat dieser Trend auch seine Schattenseiten, die auch auf unserem Arbeitsmarkt ihre Spuren hinterlassen werden.

vy73
Markus
DL8MBY