When peering with several AS at a public IXP the main goal is to route each other’s prefixes along the IXP’s switching architecture. Nevertheless sometimes a peering partner wants another peering partner to work as upstream and provide him a full table. In this case the traffic flowing as „transit traffic“ should somehow be accounted or monitored. In order to provide such functionality we invented something…

Da ich selbst jedes mal wieder von neuen anfange zu suchen wie ich ein Zertifikat, welches ich von einer Zertifizierungsstelle erhalten habe z.B. in einen Exchange 2016 Server einspiele hier der openssl-Befehl:

openssl pkcs12 -inkey <privater-schluessel> -in <zertifikat> -certfile <intermediate-zertifikat> -export -out <ziel-pfx-datei>

After I recently bought a SunSDR2 PRO I wanted to connect it to my Expert 2K-FA amplifier. The best solution I found was connecting them using the Yaesu-style band-data bits. You need to set the amplifier to Yaesu Band-Data.

Pin layout:

SUBD15 (SunSDR)     DB15 (amplifier)

2                                      14 (Band-Data B)
7                                      6 (Band-Data A)
8                                      15 (Band-Data D)
12                                     7 (Band-Data C)
13                                     12 (PTT)
15                                     4 (GND)
14                                     via 510Ohm to 14,6,15,7

Additionaly connect a chinch cable to the ALC connector of the SunSDR ending in the same DB15 plug (Pin 5 ALC, Pin 4 GND)

Then you need to set the band-data in the „Ext Ctrl“ section of your ExpertSDR software to the correct values (see the chart below).

If you have connected a radio interface either directly by RS232 or by an emulated USB port to your Mac you can’t access the interface for acquiring the frequency, mode, etc. with both programs at the same time. As MacLoggerDX has a great AppleScript interface you can create a small script that will be integrated as macro into fldigi by using the EXEC command.

The script will look like this:

tell application „MacLoggerDX“
lookup (system attribute „FLDIGI_LOG_CALL“)
delay (1)
set rawfrequency to (system attribute „FLDIGI_FREQUENCY“)
set mldxfrequency to rawfrequency / 1000000
setLogFrequency mldxfrequency
setLogMode (system attribute „FLDIGI_MODEM“)
log
end tell

The frequency needs to be converted to MHz because MLDX only wants this format. Now you can just click your macro and the QSO will be logged correctly.

I recently bought a new IC-9100 that comes with an USB interface. Through this interface 2 serial ports (based on Silicon Labs UART/USB bridge) and the audio codes are emulated to the computer – the same like on an IC-7200 or IC-7600.
I’m using a Mac and installed the latest drivers for the USB/UART bridge. When switching on/connecting the transceiver to the Mac two new ttys (e.g. /dev/tty.SLAB_USBtoUART and /dev/tty.SLAB_USBtoUART2) are created.
When I set up those parameters for example in fldigi everything works fine (PTT, CI-V, etc.). When I now switch off and on the transceiver or remove and plug the USB, everytime I do this a new /dev/tty.SLAB_USBtoUART[n] is created and the /dev/tty.SLAB_USBtoUART (without a number) is created too. The problem is now not only the always incrementing device name – the major issue is that this two devices always randomly swap; that means that one time the one without the number at the end is for CI-V operation and the other time the one with the number is for CI-V operation; so everytime I need to re-setup all rig specific values in fldigi again.
I debugged now for a few days and found out that the USB VendorID and ProductID is for both UART/USB converters the same – the only difference is the USB serial number. For the one device it is „IC-9100 0xxxxxxx A“ and for the other one „IC-9100 0xxxxxxx B“. As I understand they are both together with the audio codec on the same in the transceiver integrated USB hub. Every try to make the MacOS consider this USB serial number (e.g. a special entry in the Infp.plist of the kernel extention) failed.

Update 13.03.2011: I managed it now to have only one device when (re-)connecting the transceiver. In the transceiver are two Silabs USB-UART bridges; there is a tool from Silabs for OEMs to flash the internal EEPROM with an own Vendor-/ProductID. With this tool you can even edit all other settings like the max. current, the serialnumber, etc.
I used this tool and modified the ProductID just a little at the end with the result that the unused 2nd interface will not be determined by the driver. So now I only have exactly one (and always the same)  /dev/tty.SLAB_USBtoUART. It is not the „soft“ way solving this problem and it is very dangerous due to the fact that you might destroy your EEPROM or even the content and might never be able anymore to access it. But for me it worked; and: no risk – no fun.

Nachdem nun bei mir an allen Arbeitsplätzen ein Mac-Mini einzug gehalten hat, habe ich versucht mich auch an diese „neumodische“ Apple-Tastatur zu gewöhnen… Nach ein paar Tagen hat es mir gereicht und ich habe meine gute alte Siemens/Nixdorf/OEM KBPC-S wieder in Gebrauch. Es ist und bleibt einfach die mit Abstand beste Tastatur!

Seit geraumer Zeit gibt es vom Hersteller Ubiquiti Networks, Inc. ultra-kompakte WLAN-Geräte (Bullets) die direkt zur Montage an der Antenne gedacht sind.

Der Hersteller wirbt für das Gerät Bullet2 HP (2,4GHz „High-Power-Variante“) mit einer Ausgangsleistung von 29dBm (auf der Webseite steht sogar „…featuring up to 1000mW TX power…“. Wenn es denn wirklich so wäre, dann wäre ein solches „Bullet“ eine echte Alternative zur einer Vielzahl der bisher erhältlichen Technik.
Ich habe nun bei 6 über einen deutschen Distributor bestellten Geräten mittels einem Rohde&Schwarz Leistungsmesskopf (NRP-Z81) und entsprechendem Dämpfungsglied an den mir vorliegenden Geräten die Leistungen bei jeweils gleicher Konfiguration gemessen (802.11b/g, 1MBit, 29dBm, Kanal 1). Die Messungen ergaben eine aus meiner Sicht verhältnismäßig breite Streuung. Beim besten Gerät ist die Leistung 27,8dBm (ca. 550mW) und beim schlechtesten 24,9dBm (ca. 300mW) – das ist effektiv ein Unterschied von knappen 3dBm. Wie der Hersteller lt. Datenblatt auf 29+/-1dBm kommt, ist für mich keineswegs nachvollziehbar.

Ich habe mich dazu entschlossen meinen Kernel auf 2.6.27 zu updaten. 3 Tage hat mich die ganze Aktion gekostet. Von neuem Compiler über neue Glibc bis hin zum Firefox…

3 kurze Anmerkungen:

• als Kernel-Parameter vt.default_utf8=0 angeben, da sonst an der Textkonsole alle Umlaute nur Kästchen sind

• neuste VMWare Workstation benutzen (6.5) – bei allen älteren Versionen lassen sich die Module nicht compilieren

• mit neuen Radeon (PCIe) Grafikkarten muß man um einen ordentlich hochauslösende Textkonsole zu haben als Framebuffer-Treiber „uvesafb“ benutzen – ab 2.6.27 ist die Umschaltung zwischen den TTYs (z.B. Alt+F1, Alt+F2) spürbar langsamer geworden, d.h. man drückt wenn man sich auf tty1 befindet Alt+F2 um auf tty2 zu gelangen und sieht erst ca. 0,5s später den Inhalt von tty2; bei schnellem hin- und herschalten kann das ziemlich nervig sein

Nachdem mein erster Anlauf mich mit einem Mac anzufreunden (damals iMac) an mehreren Punkten gescheitert ist habe ich nun nochmal „Anlauf“ genommen und mir einen Mac mini zugelegt. Da eine 160GB Festplatte und 1GB RAM für die heutige Zeit doch sehr wenig ist habe ich ihn auf 4GB und eine 500GB Platte aufgerüstet. Obwohl Apple meint das gänge nicht war es überhaupt kein Problem. Im auseinandergenommenen Zustand sah der Mac mini so aus:

Ich betreibe den Mac mini jetzt mit einem Logitech UltraX Keyboard, einer Microsoft WheelMouse optical und einem 21″ EIZO TFT-Monitor (S2100). Im Gegensatz zu dem glänzenden iMac Display, der MightyMouse und dem Alu-Keyboard ist das ein riesiger Fortschritt. Man muß sich damit nicht an irgendwelche absonderlichen Eingabegeräte gewöhnen, sondern kann die Bewährten von PC verwenden.