-
Thread
Zeitbasis nichtlinear, Jitter HM1005
In meinen Schaltbildern ist der BF256B1 eingezeichnet. An welcher Stelle ist der FST627 denn eingesetzt? Hinweis: Es gibt 2 Pinbelegungen für den BF256, die sich wirklich deutlich unterscheiden. Ich bin auch schon einmal darauf hereingefallen
. Über PDPA bzw. PDPB. Ich habe die beiden Transistoren verwechselt. Im Sockel steckt nicht der BF256 so wie ich dachte, sondern der selektierte BSX19. Es kann nicht klappen wenn ich den BSX19 durch den BF256B ersetze. Der BF-Typ hat keinen Sockel. Um den zu tauschen muss das große Schirmblech
-
Thread
Schneller Mikrocontroller
XMega256A3U@64MHz ?
0x080002C8 4620 MOV r0,r4 0x080002CA 6181 STR r1,[r0,#0x18] 0x080002CC BF00 NOP 72: while (1) [/code] hast du eh nicht vergessen dem LINKER auch beizubringen dass er inlinen soll? bei mir ist das --inline_type=all
-
Thread
Crumb644 von Chip45 mit Firmware flashen
10 128 0 no 2048 8 0 9000 9000 0xff 0xff flash 33 6 256 0 yes 65536 256 256 4500 4500 0xff 0xff lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lfuse 0 0 0 0 no
oder einen anderen Fehler. Lange Rede, Kurzer Sinn... nun geht es. Die Kommunikation zw. USB und bfAlarm funktioniert. Ich danke Dir Sascha für die Hilfe. Beste Grüße toxsin
-
Thread
Warum genau dieser Transistor??
selbst bei grosser Lautstärke noch perfekt. Das Original wurde mit +/-15V bterieben. Die JFETs sind BF256A, man kann aber auch sicher einen besser erhältlichen Ersatztyp einsetzen. Für meine kritischen, aber nicht esoterischen Ohren ;-) ist das Ergebnis mehr als gut. Batteriebetrieb liegt allerdings
-
Thread
Bitmap auf TFT darstellen. Klappt, FAST!
,&s1); for (temp = 0; temp < (300*180); temp++) { //sobald wir 256 * 2 bytes also 512 geladen haben if(ucBufferCounter == 256) { ucBufferCounter = 0; pf_read(ucBuffer,512,&s1); } color.U8[0] = ucBuffer[(ucBufferCounter
Datei berechnet sich ((PixelsX*BitPerPixel)/32)*4. > { > //sobald wir 256 * 2 bytes also 512 geladen haben > if(ucBufferCounter == 256) > { > ucBufferCounter = 0; > pf_read(ucBuffer,512,&s1); > } Wieder das Problem. Was passiert bei
-
Thread
rückgekoppeltes Audion - hat jemand Erfahrung mit Drehko als RK-Steller?
schwingts nicht. Aber bei einem BC547 ist das nicht nötig. Dann würde es erstaunlicherweise mit einem BF199 ohne den Zusatzkondensator nicht funktionieren, obwohl er ein HF-Typ ist.
für UHF-Konverter und den Universaltransistor BC107 mit Ft > 100 MHz. Ca. 1976 hab ich selber mit BF241, BF245 und BF256 einen UKW-Tuner gebastelt. Bernd
-
Thread
Frage zur BFO-Frequenzspanne / 30-Meter-Rx CW
J310 noch 2N3904, nur BF245 oder BF256 und als Bipo-T BF199 oder BF494) > Eventuell sollte mit Hilfe des Pegelplans > nachvollzogen werden, was bei starken Signalen passiert. Grundsätzlich muss auf jeden Fall noch ein
> Lässt sich so eine Kaskode mit einem BF961 aufbauen Im Prinzip ja, ein DG-Mosfet verhält sich so ähnlich. Im Datenblatt steht: Power.Gain 20dB AGC-Range 50dB Mit diskreten Bauteilen sollte es mit BF245 und BF199/BF494 funktionieren
-
Thread
Technisat DigitRadio 100 IR remote control protocol (missing codes)
11000000 00111111 40BFC03F 0x02 0x03 select 01000000 10111111 00100010 11011101 40BF22DD 0x02 0x44 down 01000000 10111111 10010000 01101111 40BF906F 0x02 0x09 1 01000000 10111111 00000010 11111101 40BF02FD 0x02 0x40 2 01000000 10111111
up 01000000 10111111 00011000 11100111 40BF18E7 0x02 0x18 vol down 01000000 10111111 00110000 11001111 40BF30CF 0x02 0x0C mute 01000000 10111111 01100000 10011111 40BF609F 0x02 0x06 [/
-
Thread
Umstieg von ATmega16 auf ATmega32
identischen Einstellungen gesetzt wie am ATmega16. Einziger Unterschied: Boot Flash Section size = 256 (statt 128 wie beim 16er, da nicht möglich). Ist das vielleicht das Problem? - Ich habe in meinem Makefile MCU = atmega16 durch MCU = atmega32 ersetzt. - Ich habe mich über die Unterschiede informiert
schrieb im Beitrag #3629378: > Apropos.... zeig doch einfach mal die Fuses-Werte. Low Fuse: 0xBF High Fuse: 0xCF Extended Fuse: -- Lock Fuse 0xFF Frank M. schrieb im Beitrag #3629378: > Und bitte auch das Blink-Programm, also main.c. Das Programm ist etwas vermüllt, ist eine Bastel-Datei
-
Thread
RDS CRC Prüfbit Berechnung
8 crc: 80 9 crc: 100 10 crc: 200 11 crc: 1b9 12 crc: 372 13 crc: 35d 14 crc: 303 15 crc: 3bf 16 crc: 2c7 [/code]
crc: 0x295 A: 0x269 C: 0x30d B: 0x3fd D: 0x321 Data: 0x0010 crc: 0x3bf A: 0x343 C: 0x227 B: 0x2d7 D: 0x20b Data: 0x0011 crc: 0x206 A: 0x2fa C: 0x39e B: 0x36e D: 0x3b2 Data: 0x0012 crc: 0x0cd A: 0x031
-
Thread
AVRDUDE µC-Kompatibilität (A und PA Typen)
0xE1, 0xBB, 0xCF, 0xB4, 0x00, 0xBE, 0x01, 0xB6, 0x01, 0xBC, 0x00, 0xBB, 0xBF, 0x99, 0xF9, 0xBB, 0xAF; stk500_devcode = 0x59; signature = 0x1e 0x92 0x0a; pagel = 0xd7; bs2 = 0xc2;
paged = no; page_size = 4; size = 256; min_write_delay = 3600; max_write_delay = 3600; readback_p1 = 0xff; readback_p2 = 0xff; read = " 1 0 1 0
-
Thread
J-FET N-Channel mit gößer 70V Drain / Source Spannung für Konstantstromsenke
und höher? > Ja, SMD geht nicht. Meine Idee ist halt mindestens 3x eine Konstantstromquelle like BF256C aufzubauen wie auf dem Bild. Nur das hier dann die Z-Diode gespeist wird und nicht eine LED. Das ganze soll sich noch mit mit einer SMD-Schaltung vertragen, d.h. das ganze soll nicht zu groß werden
fet.htm Auweia!! Musstest Du mich so blossstellen...? Allerdings lassen wir sowas mickriges wie z.B. BF244 natuerlich nicht zaehlen ;-)
-
Thread
PIC24 Uart Problem
1; AD1PCFGLbits.PCFG7 = 1; // Unlock Registers __builtin_write_OSCCONL(OSCCON & 0xBF); RPINR18bits.U1RXR = 7; RPOR3bits.RP6R = 3; __builtin_write_OSCCONL(OSCCON | 0x40); initUART(); // 1. init the UART2 serial port while (1) { U1TXREG
1; AD1PCFGLbits.PCFG7 = 1; // Unlock Registers __builtin_write_OSCCONL(OSCCON & 0xBF); RPINR18bits.U1RXR = 7; RPOR3bits.RP6R = 3; __builtin_write_OSCCONL(OSCCON | 0x40); initUART(); // 1. init the UART2 serial port while (1) { U1TXREG = 0x62
-
Thread
Von uC zu Android-Smartphone per BT Daten versenden: Problem mit der Typkonvertierung
System.out.println(Integer.toHexString(z)); } ... [/code] Eclipse gibt im LogCat folgendes aus: ef bf bd 1 Jedes Byte bei bei dem das MSB 1 ist (z.B. 0xa7) wird als "ef bf bd" ausgegeben.
die Bytes so ausgeben wie sie reinkommen. > Eclipse gibt im LogCat folgendes aus: > ef > bf > bd > 1 Das ist ein UTF-8 BOM, siehe auch https://developer.android.com/reference/java/nio/charset/Charset.html
-
Thread
Z180-Stamp Modul
a0, actual 5f FAILURE (data line): Is a0, should be 5f FAILURE (data line): expected 40, actual bf
Quelle? Meine habe ich von hier: https://www.aliexpress.com/item/Free-shipping-10pcs-lot-Tmpz84c015bf-10-TMPZ84C015BF-TMPZ84C015-QFP-100-IC/32472094972.html
-
Thread
Datenblatt und SPICE-Modelle JFET gesucht
Hallo zusammen, besitze eine Handvoll alter JFET BF246C, BF256B, SFE210 und 3N211. Letztere sind sogar Dual-Gate-Typen. Ja, ich weiß, einiges davon ist obsolet, nicht für Neudesign. Teile aus Tütchen von einer Ramschmesse vor längerer Zeit sind aber
Login Seite für die Yahoo group. https://groups.yahoo.com/neo/groups/LTspice/info .MODEL BF256B NJF(VTO=-2.3085 BETA=1.09045m BETATCE=-0.5 LAMBDA=2.31754E-2 RD=7.77648 RS=7.77648 CGS=2.00000p CGD=2.20000p PB=9.91494E-1 IS=2.59121E-16 XTI=3 AF=1 FC=0.5 N=1 NR=2)
-
Thread
[V]erschenkt nostalg. AC/DC-Kalibrator
ein eingebautes Netzteil. Halbleiterliste: µA741 REF02, PMI 78L12 79L12 2 x AA112 LED grün BF256 B40C800 Verschenke ich gegen Portokosten € 3,99 als Päckchen (sollte möglich sein).
-
Thread
DS1820, Sendet außer Presence nichts zurück.
DDRD|=0x40; //Triggerung One_Wire_Send(0x55,1); PORTD|=0x40; _delay_ms(3); PORTD&=0xBF; while(1) { One_Wire_Send(0x44,0); PORTD|=0x40; _delay_ms(3); PORTD&=0xBF; One_Wire_Send(0xB4,0); PORTD|=0x40; _delay_ms(1); PORTD&=0xBF; //
delay_ms(2); //Zeit für Presence = 500uS One_Wire_Send(0x33,0); //Skip-Rom PORTD&=0xBF; //Rücksetzen One_Wire_Send(0x7D,0); //Daten Lesen PORTD|=0x40; //Setzen One_Wire_Send(0xFF,0); //DS1820 Auswählen PORTD&=0xBF; //Rücksetzen One_Wire_Send(0xFF
-
Thread
Quick&dirty - schnelle Problemlösungen selbst gebaut Bilder
Magnus M. schrieb im Beitrag #4117447: > Wie viel Speicher hat der Schredder jetzt? 256MB war'n das glaubich.
Will ein Bohrfutter von einer Handbohrmaschine lösen. Das BF ist händisch, keine Querlöcher f. Schlüssel, nur Kunststoffgriff, 1/2x20 UNC. Imbusstift im BF rutscht durch weil die 3 Backen innen auch rund sind. Ein Ölfilterschlüssel (?) muss her aber ich hab keinen
-
Thread
Video Streaming STM32 -> Z80
out (00),a SRA b SRA b ld a,b AND h out (00),a SRA b SRA b ld a,b AND h out (00),a ld a,BF out (01),a in(c),b ld a,b AND h out (00),a SRA b SRA b ld a,b AND h out (00),a SRA b SRA b ld a,b AND h out (00),a SRA b SRA b ld a,b AND h out (00),a ld a,7F out (01),a in(c
hohe Updaterate, und das mit der Synchronisation funktioniert auch. Ich habe jetzt alle 64 Bytes (256 "Takte") einen Synchpuls Z80-> STM32. Genaue tests mit verschiedenen Rechnern (Typenstreuung) habe ich noch nicht, aber zumindest an dem einen Testobjekt sitzt die Synchronisation, sodass jeder Pixel
-
Thread
Quarze ausmessen mit AD8307 (logarithmischer Verstärker)
das hatte ich bisher mit Keramik-Resonatoren nicht probiert. > Sowohl der Resonator als auch der BF199 und die Kondensatoren sind > ziemlich temperaturempfindlich. Beim BF199 könnte noch durch verringern des Basisstroms die Eigenerwärmung reduziert werden. Aber beim Resonator hilft nur isolieren
Bin mittlerweile dazu gekommen, weiter am Oszillator zu forschen. Benutze jetzt einen Colpitts mit BF256. Mit Polystyrol-Kondensatoren in der Rückkopplung driftet der Oszi zuerst eine Weile nach unten, bleibt stehen und dann geht die Frequenz wieder nach oben. Mit einer zusätzlichen Spule (Festinduktivität
-
Thread
Probleme mit CAN-Controller
benötigt wird. > > Was gibt es für Probleme mit Autosar? Der einfache Autosar Stack braucht schon 256kB Flash. Da werden die 288kB Flash beim Spansion (Fujitsu) MB9BF524M zusammen mit der Appikations-Software nicht reichen. Ansonsten ist das Spansion Teil schon gut ! Gruß von der sonnigen Terasse
-
Thread
Konstantstromquelle mit J-Fet
/luceneSearch.do?dispatch=find&keywordPhrase=610611&wt_ga=6004710017_27493053017&wt_kw=6004710017_bf256b&gclid=CKflnJ2w5LwCFZDKtAodAhQADA
nicht nur einem Hersteller produziert). Z.B, hier: http://www.datasheet-pdf.com/search.php?sWord=bf256 Das Datenblatt von OnSemi enthält Kennlinienfelder.
-
Thread
PIC32 und Fehler im Linker Script für zu ladende App
. Ich nehme derzeit einfach mal die Hälfte als Booter, die andere Hälfte als App. (512 KByte -> 256 KByte + 256 KByte), später dann feintuning der Größen. Ich orientiere mich an der App Note AN1388 von Microchip. Der Booter ist erst einmal kein Problem, da ja das alte Linker Script weiter benutzt
data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000 sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000 configsfrs : ORIGIN = 0xBFC02FF0, LENGTH = 0x10 } Jedoch erhalte ich folgende Meldung beim Linken der App: ld.exe: address 0x9d0401e0 of Object\test.elf
-
Thread
Programm ist im Tiny versetzt.
zahler1, 0xff breq led1 rjmp loop led1: ldi exor, 0x01 ; zustandwechsel auf PB0 alle 256 durchläufe eor tmp,exor out PORTB, tmp ldi zahler1, 0x00 inc zahler2 cpi zahler2, 0xff breq led2 rjmp loop led2: ldi exor, 0x02 ; zustandwechsel auf PB1 alle 65536 durchläufe
10028000818183818585078789890F8B8D8D07CF34 :1002900090999391849D139799889BDB9D8D1FDF87 :1002A000B021E383A500D5B721ADAB89BC00D5BF94 :1002B000B9B1B1B3B5006A97B8393FFB3D3D3F3F97 :1002C000C1C1C1E1C5C5C7C7CDC9CBCB4DCDEFCFEE :1002D000D9D1D3D3D5C5D757D9D9F9CBDDDDDFDF18 :1002E000E1006AE1E4E567E3E9E9EBEB656D6F6F77 :1002F000F1F1F1F3F4F4F7F3FDFD7B7FFDFDFFFF7A
-
Thread
FET-Audion Bastelei
=7.533u Vk=74.1 Cgd=6.2p M=464.7m Pb=1 Fc=500m Cgs=6.2p Kf=4.634e-002f Af=1 mfg=Fairchild) .MODEL BF245A NJF(VTO=-1.7372E+000 BETA=1.16621E-003 LAMBDA=1.77211E-002 RD=9.01678E+000 RS=9.01678E+000 IS=2.91797E-016 CGS=2.20000E-012 CGD=2.20000E-012 PB=7.80988E-001 FC=5.00000E-001) .MODEL BF245B NJF(VTO
7.77648E+000 IS=2.59121E-016 CGS=2.00000E-012 CGD=2.20000E-012 PB=9.91494E-001 FC=5.00000E-001) .model BF245C NJF(VTO=-5.0014E+000 BETA=5.43157E-004 LAMBDA=2.71505E-002 RD=1.20869E+001 RS=1.20869E+001 IS=3.64346E-016 CGS=2.00000E-012 CGD=2.00000E-012 PB=1.24659E+000 FC=5.00000E-001) .model BF256B NJF(VTO
-
Thread
AVR-GCC: Variablen in EEPROM an fester Adresse mit Initialisierung
Also so z.B.: [c] // AVR EEPROM initalization values uint8_t ee_data[E2END + 1] EEMEM = { // 256 Bytes from 0x0000 to 0x00FF 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // 0x0000 - 0x000F 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // 0x00B0 - 0x00BF 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // 0x00C0 - 0x00CF 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,