News

Starship Flight 13: Engineering in Action

🇺🇸 · Huntsville Alabama L5 Society (HAL5) - Project HALO · National Space Society

By Burt Dicht NSS Space Coast Correspondent Image: Starship 13 after “landing” in the Indian Ocean. Last week I had the opportunity to speak to a group of high school students attending the University of South Florida’s Aerospace Engineering Summer Camp. We discussed many aspects of engineering, from the challenges of designing aircraft to the complexity of building spacecraft capable of surviving launch, operating in space, and returning safely to Earth. One topic generated considerable discussion: the Engineering Design Process. Engineers define a problem, develop possible solutions, build and test a design, evaluate the results, and use what they learn to improve the next version. On paper, it is a simple flowchart. In practice, it is rarely that neat. An improvement in one area can reveal a weakness somewhere else. A successful test may answer one question while raising several more. The purpose is not to produce a perfect design on the first attempt. It is to gather the knowledge needed to make the next design better. Only a few days after my presentation, I watched that process unfold as SpaceX launched Starship Flight 13 on Friday, July 24. Like many people, I enjoy watching a rocket launch. As an engineer, however, I often find myself wondering what questions the test team is trying to answer. That perspective changes how you view a flight. The public naturally asks whether a launch succeeded or failed. Did the vehicle reach its planned trajectory? Did every objective go as planned? Were there any visible problems? Those are reasonable questions. Engineers also ask another one: What did we learn? Starship remains an experimental launch system. Ground tests and computer simulations can answer many questions, but only flight reveals how the complete vehicle responds to vibration, aerodynamic loading, thermal stress, engine transients, software commands, and the interaction of thousands of components. Flight 13 was particularly important because it was only the second flight of Starship Version 3. While the vehicle retained the familiar Starship form, the new configuration included substantial changes to structures, propulsion, software, and thermal protection. Those modifications were intended to improve performance and reliability, but they also had to be validated together in flight. Flight 12 had provided the first opportunity to test Version 3. It also exposed problems during Super Heavy’s return sequence. Heat effects on propulsion components and incorrect engine alarm settings contributed to the loss of the booster before the planned controlled splashdown. SpaceX reviewed the data, revised hardware and software, and carried those changes into Booster 20 for Flight 13. That is the Engineering Design Process as I had described it to the students: identify the problem, develop a solution, test it, evaluate the results, and repeat.Before examining the results, it helps to understand the questions SpaceX placed on the Flight 13 test card. The Questions Behind the Flight Every flight test is built around specific objectives. Together, they form a test card: the planned demonstrations and measurements that will determine what the mission teaches the engineering team. Flight 13 focused on five areas: validating the second Version 3 stack during ascent; improving Super Heavy’s return sequence; deploying 20 production Starlink Version 3 satellites; restarting a Ship Raptor engine in space; and collecting more demanding reentry and heat-shield data. The first objective sounded simple: launch the new configuration successfully. Yet there is nothing routine about flying a redesigned vehicle. Ground testing can verify individual components and subsystems, but ascent is the first time the entire stack must perform under full aerodynamic, structural, thermal, and propulsion loads. Super Heavy’s return was another major focus. After separating from Starship, the booster must flip, restart selected engines, complete a boostback burn, survive atmospheric descent, and ignite a larger group of engines for the landing burn. Each event occurs quickly, and each depends on propulsion, guidance, navigation, flight software, and vehicle control working together. Flight 13 would show whether the changes made after Flight 12 had improved that sequence. The Starlink payload represented a different kind of milestone. Previous flights had concentrated primarily on proving the vehicle. Flight 13 began testing whether Starship could perform useful work. Ship 40 carried 20 production Starlink V3 satellites. Because the mission followed a suborbital trajectory, the satellites were not intended to remain in space. Their purpose was to separate from Starship, deploy their arrays and antennas, establish radio-frequency and laser communications, and return data before reentering. Six also carried cameras intended to observe Starship and its heat shield. The mission also called for a single Raptor relight in space. Future Starship operations will require reliable restarts for orbital maneuvering, rendezvous, propellant-transfer missions, lunar operations, and departures beyond Earth orbit. A brief relight during a test flight may not look dramatic, but it validates a capability on which much more ambitious missions will depend. Finally, SpaceX planned another demanding reentry. Flight 13 included load-sensing heat-shield tiles, revised attachment methods, and changes around the aft flaps. The ascent and reentry profiles were designed to subject the vehicle to greater dynamic pressure, giving the team better information about tile retention and thermal protection under increased loads. The test card showed how the program’s questions have changed. SpaceX is no longer asking only whether Starship can launch and separate. It is testing payload deployment, in-space propulsion, thermal protection, and the elements needed for a reusable transportation system. That is why the mission could not be judged by one spectacular moment, whether good or bad. The Flight After a week of schedule changes caused by a last-second abort and then weather, Flight 13 lifted off from Pad 2 at Starbase at 6:51 p.m. EDT on July 24. Booster 20’s 33 Raptor engines ignited, and the 407-foot vehicle climbed away from South Texas. The second Version 3 stack performed well during ascent. All 33 booster engines were reported operating at liftoff, and the vehicle passed through Max Q before hot-staging just over two minutes into the mission. Ship 40 continued on all six engines while Booster 20 began its return. The booster’s initial performance was encouraging. It completed the flip and a five-engine boostback burn, a clear improvement over Flight 12. The landing burn, however, remained troublesome. As Booster 20 approached the Gulf of Mexico, only a subset of the planned landing engines ignited. Public reports differed on the precise count, and SpaceX had not released a complete engine-by-engine account when this blog post was prepared. The broad result was clear: the booster descended too quickly and struck the water harder than intended. The hard splashdown was a miss, but it did not erase the progress earlier in the return. Flight 13 showed that the flip and boostback sequence had improved while narrowing the remaining problem to the terminal landing burn and engine-relight performance. The next design review will begin with much more specific information than the team had after Flight 12. Meanwhile, Ship 40 continued through a remarkably productive upper-stage test. Beginning about sixteen minutes after launch, Starship deployed all 20 Starlink V3 satellites. The satellites established communications through radio-frequency and laser links, and SpaceX reported contact with each one. They returned telemetry and imagery during the short time available before their planned atmospheric reentry. This was not an operational satellite launch, since the payloads were never intended to reach lasting orbit. It was nevertheless an important demonstration. Starship successfully carried, released, and communicated with production spacecraft, exercising many of the functions required for future deployment missions. The test moved the program beyond simply proving that the vehicle could fly. Nearly forty minutes into the mission, Ship 40 successfully relit one Raptor engine in space. The event was brief, but the capability is central to Starship’s future. The vehicle will need dependable restarts for orbit changes, rendezvous and docking, tanker operations, and missions to the Moon and Mars. Reentry provided the most visually striking and perhaps the most consequential results. Ship 40 maintained telemetry through much of the descent using Starlink communications while the modified thermal protection system endured peak heating and aerodynamic loading. Flight imagery showed considerably less visible tile damage than on several earlier missions. SpaceX had intentionally stressed the system to obtain better data on tile retention, attachment methods, and the aft-flap areas. The ship then completed a controlled landing burn and made an intact splashdown in the Indian Ocean. SpaceX described it as Starship’s softest ocean landing to date, and the vehicle remained afloat after touchdown. The reentry result mattered for more than the imagery. A reusable upper stage must survive repeated returns without extensive tile replacement or structural repair. Flight 13 did not prove that Starship is ready for rapid reuse, but it provided a much stronger data point for the thermal protection system and controlled landing sequence. Taken together, the results were mixed but substantial. Super Heavy did not complete its planned soft splashdown. Ship 40, however, achieved nearly all of its planned objectives: a clean ascent, payload deployment, communications with all 20 satellites, an in-space engine relight, sustained reentry data, and an intact ocean landing. The upper stage advanced significantly. The booster gave SpaceX a more focused issues to resolve as the program moves forward. Looking Beyond Flight 13 Flight 13 matters because Starship’s development is tied to objectives far beyond a single test campaign. For SpaceX, the immediate goals include deploying much larger Starlink satellites and developing a launch system whose booster and upper stage can both be recovered and flown again. The economic case for Starship depends heavily on that reusability. A hard booster splashdown therefore cannot be dismissed as unimportant. Reliable recovery must eventually become routine rather than dramatic. At the same time, the upper-stage accomplishments addressed capabilities needed for future operations: carrying real payloads, restarting engines in space, maintaining communications during reentry, improving thermal protection, and controlling the ship through landing. Those capabilities also matter to NASA. NASA’s current Artemis architecture calls for Artemis III in 2027 to be a crewed demonstration mission in low Earth orbit rather than a lunar landing. Orion will practice rendezvous and docking with test versions of commercial human landing systems. SpaceX plans to use a Version 3 Starship test article fitted with a docking system, allowing NASA and SpaceX to evaluate communications, controllability, docking, and the behavior of the combined Orion-Starship stack. The Artemis III astronauts will remain aboard Orion during the Starship portion of the test. NASA now plans the first crewed lunar landing of the Artemis campaign for Artemis IV in 2028. Before astronauts can descend to the surface, SpaceX must also complete an uncrewed Starship Human Landing System demonstration at the Moon. That mission will require capabilities far beyond those attempted on Flight 13, including repeated launches, long-duration operations, orbital propellant transfer, rendezvous and docking, and a lunar landing. Flight 13 did not demonstrate that full architecture. It did, however, provide useful evidence about the Version 3 vehicle that SpaceX intends to use as the basis for its Artemis III test article and future Starship HLS development. This is where the Engineering Design Process becomes more than a classroom concept. No single flight will prove Starship ready for all of its intended missions. Progress will come through a sequence of tests, each designed to reduce uncertainty in a particular part of the system. A simple success-or-failure label cannot does not apply to tests like Flight 13. The mission succeeded in some areas, fell short in another, and produced the data needed to determine what comes next. That was the point I hoped the students at the University of South Florida would understand when we discussed the Engineering Design Process. In the classroom, the process appeared as boxes connected by arrows. Flight 13 showed what those arrows represent: test data reviewed late into the night, assumptions challenged, hardware changed, software revised, and another vehicle prepared for flight. The launch was the most visible part of the process. The engineering work that follows will determine the value of the mission. And somewhere at Starbase, Flight 14 is already being shaped by what Flight 13 taught the team. The post Starship Flight 13: Engineering in Action first appeared on NSS .

Commercial Space

Bun in Rust: hype da valutazione miliardaria o vera rivoluzione?

🇮🇹 · /root · Lamberto Tedaldi

Sfidare le leggi della fisica è un ottimo modo per attirare l’attenzione, ma sfidare le leggi della finanza tech è un modo ancora più veloce per farci alzare le sopracciglia. Se state seguendo le ultime conversazioni su Hacker News, avrete sicuramente sentito il rumore di tastiere che sbattono freneticamente: si parla del rewrite di Bun in Rust. Per chi non fosse aggiornato, l’idea è quella di prendere uno dei runtime JavaScript più veloci e ‘freschi’ del momento e riscriverlo usando la potenza bruta e la sicurezza di memoria di Rust. Il soundbite è perfetto, quasi cinematografico, tipo il momento in cui l’eroe scopre un nuovo potenziamento nel videogioco preferito. Però, fermiamoci un secondo. Prima di scaricare l’ultimo update e sentirci i nuovi padroni del web, c’è un piccolo dettaglio che non dovremmo ignorare: le valutazioni aziendali. L’articolo che ha acceso la miccia (e che merita una lettura critica) ci ricorda una cosa fondamentale: bisogna essere estremamente scettici quando qualcuno lancia una dichiarazione tecnica che sembra progettata apposta per gonfiare il valore di una società. Nel mondo tech, e specialmente in quello delle startup che cercano il prossimo round di finanziamento, il confine tra «abbiamo ottimizzato l’allocazione della memoria» e «stiamo creando una macchina da stampa di dollari» è sottilissimo, quasi invisibile. Non dico che il progetto sia una ciofeca. Anzi, l’idea di vedere Bun che evolve è eccitante e, se implementata bene, potrebbe rendere il nostro workflow ancora più fluido. Ma quando sentite parlare di prestazioni che superano l’impossibile, ricordatevi che dietro ogni riga di codice ‘rivoluzionario’ c’è spesso un team di marketing che sta cercando di convincere degli investitori che la loro tecnologia è il nuovo standard indispensabile. In Italia, tra l’altro, siamo abituati a gestire la realtà con un pizzico di sano pessimismo: non ci facciamo incantare da ogni nuova feature che arriva dai grandi hub americani. È giusto essere entusiasti della tecnologia open source e del progresso linguistico, ma non perdiamo di vista il quadro d’insieme. La vera sfida non è solo scrivere codice veloce in Rust, ma far sì che quel codice non diventi solo un altro pezzo di marketing per giustificare round di finanziamento astronomici. Quindi, teniamoci pronti a testare il nuovo Bun, a sporcarci le mani con il terminale e a vedere se le performance reggono l’urto della realtà. Ma teniamo anche un occhio critico aperto, perché nel mondo del software, come nel cinema, il montaggio può far sembrare molto più epica una scena di cui, in realtà, la metà è stata girata con degli effetti speciali un po’ troppo convenienti. Source: How is the Bun Rewrite in Rust going?

webnewsBunrustSoftwareEngineeringTechCritique

Billy Lingwood TRISKEL SAMPLE Project Space Residency – Update

🇮🇪 · Sample Studios · Matthew Whyte

“My plan to turn the Project Space into a hub of socially engaged / collaborative practice has worked out really well. I’m collaborating with fellow Sampler Paddy Dennan in bringing the community art groups we work with into the Project Space to research, develop and build the main float for this year’s LGBT+ Pride Parade, in partnership with Cork Community Pride. We’re currently preparing some intensive workshop sessions ahead of the Pride Festival over the August bank holiday weekend. We’re rooting our collaborative research in community activism, drawing on current events, archival news reels and a short film by a long-distance collaborator John Greyson (Toronto). John’s short film Gauze is a satirical reworking of the writings of Walt Whitman reframed as a call to action for the queer community to reassert our position at the frontline of anti-imperialist struggle. It will be screened in the Project Space to give some context to the work. Alongside this, I’m also engaging in further transatlantic collaboration with queer community members in Cork and Toronto, working with them on a fantastical portraiture project based on a short story called Phantom Shore by my long-term colleague Yelverton Freeman. Some really nice validation of all of this work came last week with a visit to the Project Space by Marc Miller (Canadian Culture Minister) and Dennis King (Canadian Ambassador). I got the chance to brief them on the work, which they were really open to.”

News

Kimi-3: Il nuovo colosso che vuole far tremare i giganti (e non è solo marketing)

🇮🇹 · /root · Lamberto Tedaldi

Tutti amiamo le presentazioni mondiali che promettono di rivoluzionare il mondo, ma di solito finisce che è solo un altro modo per dire «abbiamo migliorato leggermente la velocità di risposta». Con l’arrivo di Kimi-3, però, l’aria sembra essersi fatta decisamente più elettrica. Moonshot AI ha appena tirato fuori dal cilindro un mostro che non sembra voler solo partecipare alla festa, ma piuttosto prenderne il comando. Parliamo di un modello che non si limita a rispondere a domande, ma che punta tutto sul ragionamento profondo e sull’autonomia. Guardando i dati, i benchmark non sono solo impressionanti, sono quasi sfacciatissimi: in ambiti come il coding e la risoluzione di problemi logici complessi, Kimi-3 sta mettendo in difficoltà i soliti noti del settore. Ma cosa lo rende davvero diverso? Il punto non è solo la capacità di generare testo fluido, ma quella che in gergo chiamiamo «agency». Kimi-3 non è solo un chatbot che aspetta il tuo prompt; è progettato per comportarsi come un vero agente, capace di pianificare, usare strumenti esterni e gestire task multi-step con una precisione che fa sembrare i modelli precedenti dei semplici completatori di frasi. Naturalmente, per noi che viviamo tra terminal e API, la vera notizia è l’integrazione. Moonshot ha puntato tutto su un ecosistema che supporta l’uso di tool, rendendo il modello capace di interagire con il mondo reale (o almeno con quello digitale che ci circonda). Se mastichi Python o sei abituato a gestire workflow complessi, le potenzialità qui sono enormi. C’è però un piccolo «ma». Come sempre in questo settore, la questione della disponibilità e dei costi rimane il grande elefante nella stanza. Sebbene le prestazioni siano da brividi, la sfida sarà capire quanto sarà accessibile questo mostro per gli sviluppatori indipendenti e per le realtà che non hanno budget illimitati. Inoltre, l’ecosistema di Moonshot deve ancora dimostrare di poter competere con la massa critica di sviluppatori e plugin che orbitano attorno ai giganti americani. In definitiva, Kimi-3 è un segnale inequivocabile: il monopolio del ragionamento avanzato non è più una proprietà esclusiva di pochi player della Silicon Valley. La competizione si è spostata su un altro livello, e noi siamo spettatori privilegiati di una guerra tecnologica che sta diventando incredibilmente interessante. Source: Kimi-K3 Releases on HuggingFace 7/27

webnewsaiArtificial IntelligenceKimi-3Moonshot AI

Success for Sample-Studios Members – Kim Crowley

🇮🇪 · Sample Studios · Matthew Whyte

Bloomers , Cork-based feminist and artist-led publishing collective is directed by Sample-Studios member Kim Crowley and her co-founder Enid Conway. On Monday July 13th Bloomers launched an exhibition at EU Headquarters in Brussels, celebrating Ireland-based independent and artist-led publishing and Bloomers’ work over the last 8 years. The exhibition showcased Bloomers publications alongside a collection of independently published books, zines and publications from their personal collections. They were invited by Michael McNamara MEP and Renew Europe as part of the cultural programme for the Irish Presidency in the EU this year. Bloomers’ co-directors Kim Crowley and Enid Conway, spoke about the potentials of publishing to widen access to art and ideas. As a country, Ireland has a long history of storytelling as well as censorship and oppression, both of which have been generative in our artistic and literary identity. The exhibition celebrated this while highlighting the importance of artist-led publishing as a tool for connection and cultural exchange. Photo by Laurie Dieffembacq

News

Panic Button o Prova di Colpevolezza? Il dramma di GrapheneOS in aeroporto

🇮🇹 · /root · Lamberto Tedaldi

Se un software decide di cancellare tutto proprio mentre sei sotto i riflettori della sicurezza aeroportuale, hai un problema di privacy risolto o un problema legale imminente? Il caso di Tunick, un uomo di Atlanta, sembra uscito da un episodio di ‘Mr. Robot’. Durante un controllo di routine, il suo smartphone con GrapheneOS ha eseguito una procedura di wipe automatico. Risultato? L’accusa non l’ha presa bene e ora si ritrova con un processo sulle spalle. Per chi non mastica abbastanza codice, GrapheneOS è quel gioiello open source basato su Android che trasforma un Google Pixel in una fortezza digitale, offrendo una protezione della privacy che farebbe impallidire un agente dell’FBI. La funzione in questione è quella che noi amiamo: la possibilità di impostare un codice che, se inserito (o se il dispositivo viene manipolato in certi modi), innesca la distruzione immediata delle chiavi di cifratura. È il ‘Kill Switch’ definitivo. Se sei un maker o un appassionato di sicurezza, pensi: ‘Geniale, i miei dati sono al sicuro’. Se sei un procuratore americano, pensi: ‘Ehi, sta distruggendo prove!’. Certo, parliamoci chiaro: siamo in Italia, e se un poliziotto ci ferma per un controllo, la nostra prima reazione non è attivare un protocollo di autodistruzione dei dati, ma sperare che non trovi quel vecchio setup di Raspberry Pi pieno di script sperimentali che non dovrebbero stare in tasca. Le leggi americane sono spesso un teatro dell’assurdo dove il concetto di ‘colpa’ si mescola con l’intralcio alla giustizia in modi che da noi sembrano fantascienza. Il punto non è però la legalità del wipe, ma il dilemma etico. Da un lato, abbiamo il diritto fondamentale di avere un dispositivo che non sia una spia aperta nelle nostre tasche, un ecosistema dove il controllo è nelle mani dell’utente e non di un server in California. Dall’altro, c’è la realtà brutale delle autorità che vedono ogni barriera crittografica come un muro costruito per nascondere qualcosa. Speriamo che la sentenza non diventi un precedente pericoloso per chiunque utilizzi software che, per design, non permette l’accesso non autorizzato. Perché se domani un giudice decidesse che avere un sistema operativo sicuro è di per sé un atto sospetto, allora la vera ‘zona grigia’ non sarà quella dei nostri database, ma la nostra stessa libertà digitale. Nel frattempo, un consiglio per i colleghi nerd: se usate GrapheneOS, assicuratevi di avere un buon avvocato… o almeno un backup che non si autodistrugga ai primi segni di stress! Source: US citizen charged after GrapheneOS phone wipes during airport search

webnewscybersecurityGrapheneOSopensourceprivacy

Other

Gereedschap

🇳🇱 · Hackalot · Iron

Verwijdering van CO melder, want dat is geen gereedschap. ← Oudere versie Versie van 27 jul 2026 21:54 Regel 55: Regel 55: | Gehoorbescherming | Gehoorbescherming | Aantal: 4 | Aantal: 4 |- | [[Bestand:Gereedschap-Koolmonoxidemelder.jpeg|frameless|100px]] | ELRO Koolmonoxidemelder | [[Gereedschap:ELRO-Koolmonoxidemelder]] |- |- | [[Bestand:Gereedschap-Metaalschaar.jpeg|frameless|100px]] | [[Bestand:Gereedschap-Metaalschaar.jpeg|frameless|100px]]

Apresentações relâmpago

🇧🇷 · Garoa Hacker Clube · Gabriel Almeida

Apresentações relâmpago no Garoa ← Edição anterior Edição das 15h57min de 27 de julho de 2026 Linha 5: Linha 5: É importante usar um relógio ou timer visível para o público e ser bastante rígido quanto a principal regra: Quando o tempo alocado termina a plateia aplaude e é simplesmente impossível continuar, permitindo que a próxima apresentação comece rapidamente. É importante usar um relógio ou timer visível para o público e ser bastante rígido quanto a principal regra: Quando o tempo alocado termina a plateia aplaude e é simplesmente impossível continuar, permitindo que a próxima apresentação comece rapidamente. Esse formato de apresentações é muito apreciado nos encontros e conferências da comunidade Python, tendo também sido utilizados no Garoa nos encontros de final de ano da [[Noite de Processing], entre outras ocasiões. Esse formato de apresentações é muito apreciado nos encontros e conferências da comunidade Python, tendo também sido utilizados no Garoa nos encontros de final de ano da [[Noite de Processing ] ], entre outras ocasiões. == Próximos eventos == == Próximos eventos ==

Próximos Eventos

🇧🇷 · Garoa Hacker Clube · Villares

← Edição anterior Edição das 01h31min de 27 de julho de 2026 Linha 19: Linha 19: * '''Quarta, 15/JUL/2026 16h00 às 20h00:''' [[De boa no Garoa]] - versão Jogos de Tabuleiro * '''Quarta, 15/JUL/2026 16h00 às 20h00:''' [[De boa no Garoa]] - versão Jogos de Tabuleiro * '''Quinta, 16/JUL/2026 19h00 às 22h00:''' [[Open Hack Night]] * '''Quinta, 16/JUL/2026 19h00 às 22h00:''' [[Open Hack Night]] * '''Quinta, 23/JUL/2026 19h45 às 22h00:''' - [[Reunião de 23/7/2026|Reunião do Conselho Manda Chuva]] * '''Quinta, 23/JUL/2026 19h45 às 22h00:''' [[Reunião de 23/7/2026|Reunião do Conselho Manda Chuva]] * '''Quinta, 27/AGO/2026 19h00 às 22h00:''' [[CMC]] * '''Quinta, 27/AGO/2026 19h00 às 22h00:''' [[CMC]] * '''Sexta, 31/JUL/2026 19h00 às 22h00:''' - Noite de [[apresentações relâmpago]] (lightning talks) * '''Sexta, 31/JUL/2026 19h00 às 22h00:''' Noite de [[apresentações relâmpago]] ( '' lightning talks '' ) O Garoa também disponibiliza sua agenda destas outras formas: O Garoa também disponibiliza sua agenda destas outras formas:

Próximos Eventos

🇧🇷 · Garoa Hacker Clube · Villares

← Edição anterior Edição das 01h12min de 27 de julho de 2026 Linha 20: Linha 20: * '''Quinta, 16/JUL/2026 19h00 às 22h00:''' [[Open Hack Night]] * '''Quinta, 16/JUL/2026 19h00 às 22h00:''' [[Open Hack Night]] * '''Quinta, 23/JUL/2026 19h45 às 22h00:''' - [[Reunião de 23/7/2026|Reunião do Conselho Manda Chuva]] * '''Quinta, 23/JUL/2026 19h45 às 22h00:''' - [[Reunião de 23/7/2026|Reunião do Conselho Manda Chuva]] ⚫ * '''Sexta, 31/JUL/2026 19h00 às 22h00:''' - Noite de Lightning Talks * '''Quinta, 27/AGO/2026 19h00 às 22h00:''' [[CMC]] * '''Quinta, 27/AGO/2026 19h00 às 22h00:''' [[CMC]] ⚫ * '''Sexta, 31/JUL/2026 19h00 às 22h00:''' - Noite de [[apresentações relâmpago]] (lightning talks) O Garoa também disponibiliza sua agenda destas outras formas: O Garoa também disponibiliza sua agenda destas outras formas:

tool - removed - external edit (Unknown date)

🇨🇦 · VHS · Anonymous (anonymous@undisclosed.example.com)

Equipment and Tools at VHS Many tools here can be dangerous. All dangerous tools are members only. Non-members are welcome to use our soldering irons, hand tools, and test gear. When you add tools, please put follow this template! ---------- 3D Printing

User:Nthmost/MeetingNotes Previews/Meeting Notes 2026 07 22

🇺🇸 · Noisebridge · Nthmost

Auto-posted meeting notes for 2026_07_22 (meetingnotes) New page * For the full meeting facilitation guide (roles, agenda, post-meeting tasks), see [[Meeting_Notes_Reference|Meeting Instructions Reference]]. JULY 21st 2026 MOD - NEWMAN {{meetings2026}} These are the notes from the [https://www.noisebridge.net/wiki/Category:Meeting_Notes The XXXth Meeting of Noisebridge]. {|class="wikitable" style="text: left;" ! style="text-align:left;"| Date | 2026-07-22 |- ! Note-taker[s] | Heather, Naomi | ! Moderator[s] | Newman |} {|class="wikitable" | [[Meeting_Notes_2026_07_15|Previous Meeting]] | [[Meeting_Notes_2026_07_29|Next Meeting]] |} == Meeting Summary == * New Core members: * New Access members: = Introductions = name + worst pizza topping Newman - corn Blitzkrieg - onions Heather - pepperoni Zacchae - raw onions Jet - boiled eggs WE/Z - wasabi Corey - raisins. also the worst cookie ingredient Hyeonseop - pineapple Khalila - corn Jar - broccoli Constantine - pineapple k014 - nails Gwen - fiber Daniel (web) - black olives Jonathan - natto Sam - kale chips Naomi - peppermint patties Elan - unannounced pinenuts at places trying to be fancy (partner is allergic and this has ruined an evening) Daniel (solderfumes) - anchovies = Short announcements and events = WE/Z - going to ICML(?). chip design/etc. event Heather - guild meetings: sewing July 23rd, 3D printing next week (day TBD, see discord) Jet - open sauce afterparty donation moneys! Braelynn thanks the community for the oppt'y to tear the house down as a DJ = Excellence = '''Our One Rule is to Be Excellent to Each Other.''' What does that mean? Please see our page on [[Excellence]] ! Naomi: in juggling, you can't throw a perfect throw every time. so you adjust and catch it == Anti-Harassment Policy & Community Standards of Excellence == Noisebridge has an [[Anti-Harassment Policy]]! Everyone is expected to follow the Anti-Harassment Policy, please familiarize yourself with it.) For approachable & specific guidelines see: [[Community Standards]] Please note: '''https://safespace.noisebridge.net/ is one way to quickly raise issues which will be seen by people in Discord.''' == Brief Kudos == WE/Z: Jet for organizing open sauce Blitzkrieg & Heather: k014 aka Alex, for SLA printer work LX: Carl for getting FT working again after Open Sauce Elan: Chris, Daniel, and Daniel for last-minute party supply run = [[Guild]]s & [[WG]]s = Music: meeting on July 29th at 7pm Treasury: made just under $7k at opensauce party. brief list of expense reimbursements. reminder to coordinate and not double-up on expenses -- perhaps ppl can write on Zulip in the treasurer guild channel (?) to make sure you're not buying something someone already bought. Woodshop: new decibel meter -- idea is to put ear protection next to decibel meter and mount decibel meter * $1300 for Solderfumesandtea Daniel * $150 for Josh's UHaul * $315 for Kevin's OrangePi = New Members/Access Members = Khalilah is interested in becoming an Access member. = Financial Report = '''Anarchist societies under a capitalist state need money to survive and thrive, yo.''' * Monthly revenue, expenses. Big projects. Big fundraising events. Reserves in bank. * Any other details by those participating in handling our financials * The latest financial reports from the treasurer _may_ be available at https://noisebridge.net/wiki/Finances == Spending Needs == Kevin: rented Uhauls ~$150, also a lost OrangePi == Fundraising Update == [Khalila has a discussion item] = Consensus Items = = Discussion Items = * Daniel: who gets to use the extra keg? it's 100% full! * Heather: door opener being turned off overnight * Khalila Ada elevator * Naomi: how to encourage artists & accrue more art in the space * == 1: what to do with the leftover keg? == {{DiscussionItem| | topic = what to do with the leftover keg? | raised_by = Daniel (web) | seeking = ideas... decision? }} }} Daniel: who wants a whole keg of beer? Sam: refill all the bottles in the FT! Daniel: That's a bad idea : food incubator that does catering, etc. Chris: the physical keg has to be returned, is the problem [chatter about hosting another party] Solderfumes: keg will go bad in about 3 weeks, we should just have a big party w/ some grapefruit flavoring like a rattler or something. also as a nonprofit we can apply for a 1-day alcohol permit to sell alcohol. Chris: what's the timeline like on that? '''Solderfumes:''' something like a week? maybe? '''Elan:''' maybe if we have a non-tuesday meeting we can have a social one that starts w/ a keg? '''Lucifer:''' what about board games and other stuff at that too '''DanieL:''' sounds like we'll have some kind of rager '''Newman:''' can you guys work this out offline? '''Daniel:''' yeah. we can't legally sell alcohol Jean-Jaques: refrigerate it? == 2: door opener being turned off overnight/when closing == {{DiscussionItem| | topic = door opener being turned off overnight/when closing | raised_by = Heather | seeking = decision/outcome/advice/[?] }} once a month i come in and the door opener doesn't work b/c it's been switched off (by a human). the middle position is a position b/c it turns off, disables key card and also ADA. let's make this stop happening. '''Newman:''' so the only reason why this happens... '''Heather:''' is someone screwing up, yeah. I've tried making it so you can't touch it, but Ken apparently uses the down position so we can't just disable it. '''Jonathan:''' if it's simply changing a 3-pos to 2-pos switch, we could do that '''Chris:''' let's try maybe adding an extra switch -- put it on top where it's not visible so we don't lose the functionality. '''Newman:''' can you guys collab and make that happen? == 3: not removing art without forethought == {{DiscussionItem| | topic = not removing art without forethought | raised_by = Naomi | seeking = decision/outcome/advice/[?] }} Naomi: encouraging artists & NB to accrue art. A lot of this is b/c of Open Sauce. A lot of things like Flaschentachen keep being taken to Open Sauce, b/c we dont' make new things. Another half, a complaint I unfortunately have to make: I put a piece of art in the doorway (a hexagon light), which got taken down - I wasn't okay with this, b/c it wasn't installed in a removable+re-installable way. Having worked in an art space, a big mood killer is when there's a disrespect for the value of the choice of how and where to install it. We should know who put it up, and if they're still around, it would be more excellent to ask them. I'd also like to never ever take the FT again. Elan: I think it's a good idea to encourage art, I think a DNH sign would solve a lot of issues [Naomi shakes her head here]. Previously, people have put up art, I thikn it's cool but it takes up space. NB being a do-ocracy, people think they can do stuff to the art. For the FT, I think it'd be a good idea to have a DNH on it (and maybe the dragon). Naomi: You've just named and put on display all the cultural things that I think are shiftable. DNH signs are often not respected, especially the older they get. To me it would be sensible to not tear down things that add to the space. [current behaviour] discourages artists from sticking around and contributing. Lucifer: so yeah what about plaques [more or less] [Naomi: nods] Daniel: i had 2 things brought to opensauce and they were broken. not ideal. i kind of accept that this is just the Entropy of the space. Wheezy: so jet and i were exhibiting and by far the #1 thing that attracts ppl is the FT. it's a modular thing that will continue to be shifted, it's not always been the way it is now. we're always shifting the thing. taking it to OpenSauce brings a lot of attention to us. Daniel's art: we're gonna fix it. Naomi's hexagon: we should always source the creator and ask them if we can take it. Heather: the hexagon, it's a bit of an accessibility thing and it was the best lighting in that area. and i expressed some irritation w/ it as it was happening. so for days there was poor illumination in that area Kevin: i feel like there could be some advanced planning, i dunno??? [yeahhh! --nthmost]. Start a few months earlier, brainstorm, stuff like that. and maybe we'll create something new and exciting as an alt. to FT. Daniel: FT is big, we bring it b/c it's big, we can't have a big thing every year. Sam: talking to Brennan, was talking about how to revamp it so it's easy to move Chris: that's different thing! Naomi: yeah no one's really excited about FT, that's not going to get Noisebridge in Maker Magazine or whatever. Kevin: yeah we could build something really big and then sell it Null: sure maybe we have something alongside the FT, not always rest on the FT as an installation, make a new thing and optionally take the FT. Chance to be creative w/ constraints here. Lucifer: i feel like if we make a plan, a yearly thing, something we work on together every 6 months, we can make a big deal of it. create bigger things together, get creative, pull in more artists. a little more planning goes a long way. LX: The dragon gave out sparks during the party and someone tried to disconnect a part of it so it wouldn't cause an electrical fire, that's currently poking out of its board enclosure. Related: how to take care of big and sometimes accident-prone art projects. all related... probably art pieces like this need a maintenance document. Corey: from other arts orgs i've been in, they have an event, they have a lot of ppl going, they come up w/ ideas and as a commnunity we share & decide which one we'll all work on together. so for these big conferences you have a date you have to be done by. choosing a 4-month period where you're writing a proposal, taking a few weeks to discuss, at least a month of time to build, etc. Elan: NB does a pretty good job at encouraging art in the space... i think NBers won best project at Maker Faire last year with the Coffee Table. The reason that project came together was a lot of organization, let's make a coffee table or whatever, getting lots of ppl involved. i think the way to approach is to get ppl on board w/ the idea and try and gather around it. Doesn't seem like a policy will do the trick here. Jean-Jaques: we had 2 murals at the old space --- we did outreach to Cal College of the Arts, 2 guys presented themselves, showed what they planned to do. too bad we lost it when we moved. has anyone done something reaching out to any arts colleges, etc? Naomi: i have a stack of NFC tags you can scan to find out about an installation Newman: definitely, ok let's close this one down. == 4: elevator / ADA (grant proposal?) == {{DiscussionItem| | topic = elevator / ADA (grant proposal?) | raised_by = Khalila | seeking = consensus }} Khalila: I dropped a proposal into Discord and a few other places. was discussing this w/ Lucifer. right now 2nd floor is only accessible by stairs, excludes ppl with ADA restrictions. installing an elevator ensures we live up to our values. i am looking for consensus, that ppl like this idea. Heather: that written proposal probably won't be discussed today - community needs time to read through it Lucifer: the place it would best be is behind the 3d printing room. Corey: we met today w/ someone who installs ADA hardware (David Lindsor). i was part of a discsusion like thsi about 2-3 hyears ago. we deided the best place would be to exit right where the stairs come out. so whoever comes in w/ a wheelchair gets a similar experience to an able-bodied person. we can either get an "elevator" or a "lift". Lift: you have to manually control it, doesn't have brains, a human is in the loop, can ONLY be used by people (on pain of fine by city). Elevator: has its own sensors + intelligence, can be used for freight and people up to 1000 lbs. installation challenges: to install an elevator, you need to cut through the floor. $180k (this is all in the #accessibility channel on Discord). Lift: costs $65k - challenge in SF you're not supposed to build them past 12 ft and we are 15.5ft. we can get a "variance", probably a slam dunk to do so. I see this as incredibly valuable, no need for mods except for cutting into the (upper / second storey) floor and installing cross beams for support. Jonathan: one of the things in this discussion is that the prep of the space could be done by a general contractor (or under its supervision) and then the elevator can be put in. Corey: we'd have to find some way to build the shaft. design it, etc. could just be frame and gypsum board. Loren: glad to hear these numbers. we have a 10 year lease locked in going up 3% every year. but maybe we take the oppt'y to renegotiated. ends 2030. Lucifer: reasoning why we chose this spot, it has the least electrical and other stuff around it. and when we do the lift or elevator we may as well redo the floors at the same time. Derek: has this precluded moving NB to a single-level place? Naomi: i would strongly precaution thinking about a move. it is culturally expensive. this space was a shadow of its former self for years, and part of that was the pandemic, but a lot of that is just that it's really, really exhausting to set up a hackerspace. the other thing is that improving a space makes a property more valuable. so it's potentially a point of negotiation w/ our current landlord: "we're a tenant that improves this space." Chris: speaking of landlord, anything like that would need their approval. if we have a "build to suit" lease... Loren: the lease PDF are all available on the wiki Corey: last time we talked to the landlord he wasn't interested in any of this Naomi: well the landlord's not been interested in fixing our bathrooms, so. Heather: if we change up the 3D printing area let's take the opp'y to make it all better. current room is cramped. Lucifer: no no, it'd be BEHIND it, not through it. nondestructive. so you'd come up Loren: if we're bothering to put up a shaft, it's definitely worth folding in some replanning / revamping to make everything better. Corey: one of the reasons we put it at the front of the stairs is there's already activity there Khalila: sources from grants (possible): there are programs that help you get access to specific grants, like $200, but you can do this through the local library Naomi: if you succeed at this a lot of ppl will see you as leading the charge to get this done, are you interested in being seen as that person? Khalila: i'm happy to be seen as the organizer to keep the project together, yes, ppl can come to me for that. Kavya: we need to decide on whether it's a lift or an elevator, right? Chris: right, probably contingent on the grant size we end up getting. Khalila: i'm gonna shoot for $200k -- for a real elevator. Newman: yeah maintenance comes to mind, do lifts break more? Khalila: that's why i am going for $200k so we have buffer set aside for repairs, etc. Corey: the downside is a little sacrifice in real estate upstairs (for an elevator), so we'd be looking at losing the sewing room and Jonathan: if we devloped the list of questions my contact is happy to talk through all this. Kevin: Jonathan: a lift doesn't get you ADA approval, you can't move a wheelchair. Loren: it feels like this needs a lot of coordination, hoping there's a place to hold this as a long discussion, so for better quality discussion we should make sure this discussion isn't beholden to Naomi: [he means] make a breakout group LX: is there a way we could add a shaft to the side of the building instead? Newman: let's find out about property lines Loren: given the stairs it might have to go in place of the downstairs bathroom. Newman: great, breakout group, go over the meeting notes together and talk more. == 5: we need better electrical circuits == {{DiscussionItem| | topic = we need better electrical circuits | raised_by = Blitzkrieg | seeking = consensus }} Chris: we need more circuits. more outlets. most of the woodshop is off a single breaker which means it blows if 2 ppl are using power tools at the same time. Naomi: YEP!!! Heather: break room and music room share a breaker, so the entire north wall of the music room is the same breaker as the one running ktichen appliances. it'd be great to have more outlets, like the rest of the north wall of the music room. Daniel: we could do DC rails Chris: that only helps a little bit Daniel: it helps with not-enough-outlets for sure Elan: we "just" got a bunch of electrical outlets done, so if anyone wants to talk to them and get a new estimate Chris: I'll start the estimate by giving them a kick in the ass for not doing it right the first time. Elan: talk to JD, some personal relationship there Null: like... did they just do what we told them to do? Loren: we told them to keep the budget down. :) Naomi: I have a contact, guy who's a security guard during that rave a month ago, he says he'd like to cut NB a deal but he works for an electrician company. Got his number, can call him up. Newman: great, let's all talk to Luis, get a channel going or whatever. == 6: resin printers == {{DiscussionItem| | topic = resin printers | raised_by = k014 | seeking = awareness }} }} The resin printers are working, but are dangerous. I recommend we do not use them (for now). We should move the resin printers to a diff't location to sit on a proper desk to work with, and suitable ventilation. '''Corey:''' there's a room in back, could we use them? '''Daniel (web):''' I mostly never see them get used, and when they do get used they get messed up by the operators. I suggest trying to sell them. '''K014:''' I will buy one! '''Loren:''' People have used them, [notetakers missed some of this], mention of people who've had previous interactions with these printers. '''Blitzkrieg:''' The backroom _has_ been earmarked for a machine shop expansion for several months. '''Kavya:''' I don't think "nobody knows how to use this, so we should sell it" is a good argument. The whole point of a makerspace is so people can learn how to use things. '''Naomi:''' I think if someone experienced willing to say "in this environment, they're not suitable", it's worth listening to that person. '''LX:''' there are several 3d printer companies that make things that deal w/ fumes, we can experiment w/ vents on carts. was talking to Loren about a more permanent high-quality vent. resin also needs a sink, we should have a portable sink for it. i have a use case for it, others do too. LINK TO SCRUBBER: https://www.youtube.com/watch?v=LjShyRvu5mM and https://info.phrozen3d.com/products/phrozen-air-purifier-max '''Loren:''' i brought in a fan that's now sitting near the laser which could maybe serve as a mainline fan to make fumes go up and through the chimney. dispersal should be fine. also brought another fan for ventilation elsewhere. this could also help 3d printing ventilation. '''HEather:''' so wrt decomissioning or removing them, "not using them" is a weak reason, but if it's a safety concern that's a stronger reason. '''Jonathan:''' "in its current state this is a safety issue" so i agree let's not use them in the immediate term until we figure out how to operate them properly. '''Alex:''' i'll take pics and suggest at least 5 diff't locations around NB to put them. as soon as we find a solid DESK to put them. I don't think we need a sink. just ventilation. '''Newman:''' so we should probably put something over those printers to indicate they shuldn't be used. '''Alex:''' desperately need a desk to put stuff '''Heather:''' could we wait on where to put it? let's discuss in a 3d printing guild meeting. '''Alex:''' i would prefer to just move them b/c they're oeprational, just not good to use right now. = Do-ocratic Task Board = Participation also means doing stuff to contribute to the space. Propose new tasks or pick some tasks from [https://github.com/noisebridge/buildout-capp Github], from what needs to be done around you, or whatever, and see if someone will sign up to work on that task. Anyone can sign up and it's a great way to show you are contributing! = End of Meeting = [[Category:Meeting Notes]]

Usuário:Gwiethaus/KiCad/Footprint - Tipos e Dimensões de Componentes

🇧🇷 · Garoa Hacker Clube · Gwiethaus

Parte 2 – Encapsulamentos de Circuitos Integrados ← Edição anterior Edição das 16h29min de 27 de julho de 2026 Linha 168: Linha 168: =Parte 2 – Encapsulamentos de Circuitos Integrados= =Parte 2 – Encapsulamentos de Circuitos Integrados= <br> <div style="text-align: justify;"> Antes de conhecer cada encapsulamento em detalhes, é interessante observar como eles podem ser agrupados em famílias. Cada família possui características mecânicas próprias, como a disposição dos terminais, a tecnologia de montagem e a aplicação típica. Essa classificação facilita a identificação do encapsulamento mais adequado para cada projeto e serve como ponto de partida para a escolha do footprint correspondente. Antes de conhecer cada encapsulamento em detalhes, é interessante observar como eles podem ser agrupados em famílias. Cada família possui características mecânicas próprias, como a disposição dos terminais, a tecnologia de montagem e a aplicação típica. Essa classificação facilita a identificação do encapsulamento mais adequado para cada projeto e serve como ponto de partida para a escolha do footprint correspondente. <br> '''Tabela 2''' - Principais famílias de encapsulamentos para circuitos integrados com algumas características, aplicação, espaçamento entre terminais, técnica de soldagem empregados e níveis de dificuldade. '''Tabela 2''' - Principais famílias de encapsulamentos para circuitos integrados com algumas características, aplicação, espaçamento entre terminais, técnica de soldagem empregados e níveis de dificuldade. Linha 385: Linha 391: É importante lembrar que a família do encapsulamento define apenas as características mecânicas do componente, como suas dimensões, disposição dos terminais e método de montagem. Ela não determina sua função elétrica. Por exemplo, um amplificador operacional, uma memória EEPROM e um registrador de deslocamento podem compartilhar exatamente o mesmo encapsulamento SOIC-8, embora desempenhem funções completamente distintas. É importante lembrar que a família do encapsulamento define apenas as características mecânicas do componente, como suas dimensões, disposição dos terminais e método de montagem. Ela não determina sua função elétrica. Por exemplo, um amplificador operacional, uma memória EEPROM e um registrador de deslocamento podem compartilhar exatamente o mesmo encapsulamento SOIC-8, embora desempenhem funções completamente distintas. </div> ==✅Encapsulamento DIP (Dual In-line Package)== ==✅Encapsulamento DIP (Dual In-line Package)==

Usuário:Gwiethaus/KiCad/Footprint - Tipos e Dimensões de Componentes

🇧🇷 · Garoa Hacker Clube · Gwiethaus

✅Armadilhas do Encapsulamento SOIC/SOP ← Edição anterior Edição das 11h29min de 27 de julho de 2026 (7 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) Linha 1 604: Linha 1 604: Para se proteger desse erro, nunca confie apenas na sigla do nome do pacote (encapsulamento). Sempre verifique no datasheet do componente específico que vai adquirir e verifique duas medidas fundamentais: Pitch (Espaçamento entre pinos) se é de 1,27 mm e Body Width (Largura do corpo de plástico) de 3,9 mm (150 mils) ou 5,3 mm (208 mils). Para se proteger desse erro, nunca confie apenas na sigla do nome do pacote (encapsulamento). Sempre verifique no datasheet do componente específico que vai adquirir e verifique duas medidas fundamentais: Pitch (Espaçamento entre pinos) se é de 1,27 mm e Body Width (Largura do corpo de plástico) de 3,9 mm (150 mils) ou 5,3 mm (208 mils). <br> '''JEDEC vs. EIAJ: Normas Americana e Asiática de Encapsulamentos SMD''' ---- Se você já projetou uma placa de circuito impresso (PCB), provavelmente já passou (ou ainda vai acontecer) por uma situação frustrante: o circuito integrado chegou da China, mas os pinos dele simplesmente não alcançam as ilhas de solda (''pads'') que você desenhou com tanto cuidado. Você confere o datasheet, e o componente está rotulado como um simples SOP ou SOIC. Afinal, o que deu errado? Essa incompatibilidade clássica acontece por causa de uma guerra silenciosa de padronização industrial entre duas potências tecnológicas: os Estados Unidos (norma JEDEC) e o Japão/Ásia (norma EIAJ/JEITA). Entender essas diferenças é vital para qualquer profissional ou entusiasta de eletrônica. Quando a tecnologia de montagem em superfície (SMD) explodiu nos anos 1980, a indústria precisava reduzir o tamanho dos antigos chips Through-Hole (DIP). Duas entidades criaram regras para essa redução: A Norma Americana (JEDEC): Criada pelo '''Joint Electron Device Engineering Council''', sediado nos EUA. Ela padronizou o formato SOIC (Small Outline Integrated Circuit). A Norma Asiática (EIAJ / JEITA): A '''Electronic Industries Association of Japan''' (hoje chamada '''JEITA''') criou o padrão SOP (Small Outline Package). A raiz de toda confusão: O termo genérico "'''SOP'''" virou sinônimo popular de "chip retangular com pinos asa de gaivota em dois lados". Por causa disso, distribuidores globais e sites de e-commerce '''misturam as nomenclaturas''' e vendem chips asiáticos chamando-os de SOIC e vice-versa. '''Diferença Crucial: A Largura do Corpo (E1)'''<br> O '''passo entre os pinos (Pitch, parâmetro e)''' é idêntico em ambos os mundos: 1,27 mm. A grande armadilha está no corpo plástico ('''parâmetros E1 e E'''). A tabela abaixo faz uma comparação direta das categorias de largura: <br> '''Tabela '''- Diferença de SOIC e SOP {| class="wikitable" ! Tipo/Categoria ! Norma ! Largura Corpo Plástico (E1) ! Distância Total entre Pontas (E) ! Onde mais usado |- | SOIC Narrow<br>(Estreito) | JEDEC (EUA) | 3,90 mm (150 mils) | ~6,00 mm | Chips de baixa contagem de pinos (8 a 16 pinos) |- | SOP Standard (Asiático) | EIAJ / JEITA (Ásia) | 5,30 mm (208 mils) | ~7,80 mm | Memórias EEPROM, Flash antigas, drivers industriais |- | SOIC Wide (Largo) | JEDEC (EUA) | 7,50 mm (300 mils) | ~10,30 mm | Chips de alta contagem de pinos (16 a 32 pinos) |} {{Mbox | icone = ⚠️ | cor = #e53e3e | fundo = #fdf2f2 | texto = '''Erro Fatal''': Se você desenhar uma placa usando o componente SOIC Narrow (3,9 mm) e comprar um chip SOP Asiático (5,3 mm), o corpo do chip será largo demais e as pernas dele ficarão para fora das ilhas de solda da PCB. }} <br> '''Portanto, quem é o SO-14, por exemplo?''' '''Portanto, quem é o SO-14, por exemplo?'''

Apresentações relâmpago

🇧🇷 · Garoa Hacker Clube · Villares

← Edição anterior Edição das 01h28min de 27 de julho de 2026 (Uma revisão intermediária pelo mesmo usuário não está sendo mostrada) Linha 1: Linha 1: === Apresentações relâmpago === === Apresentações relâmpago === Também conhecidas como "lightning talks" são palestras ou apresentações de apenas alguns minutos (em geral 5 ou 7 minutos) e muitas vezes com o tema livre. Também conhecidas como "lightning talks" são palestras ou apresentações de apenas alguns minutos (em geral 5 ou 7 minutos) e muitas vezes com o tema livre . As pessoas se inscrevem para apresentar um assunto do seu interesse, divulgar um projeto ou uma causa. O tempo curto exige concentrar a informação, e a plateia se beneficia de uma diversa quantidade de assuntos interessantes em um curto período de tempo . ⚫ É importante usar um relógio ou timer visível para o público e ser bastante rígido quanto a principal regra: Quando o tempo alocado termina a plateia aplaude e é simplesmente impossível continuar, permitindo que a próxima apresentação comece rapidamente . ⚫ Esse tipo de formato é muito apreciado nos encontros e conferências da comunidade Python, tenho também sito utilizados nas [[Noite de Processing]] do Garoa , nos encontros de final de ano. ⚫ Esse formato de apresentações é muito apreciado nos encontros e conferências da comunidade Python, tendo também sido utilizados no Garoa nos encontros de final de ano da [[Noite de Processing], entre outras ocasiões . ⚫ É importante usar um relógio ou timer visível parar o público , quando o tempo termina a plateia aplaude e é simplesmente impossível continuar, permitindo que a próxima apresentação comece.

tools - Add mortise machine to Woodworking section

🇨🇦 · VHS · ccressent (ccressent@undisclosed.example.com)

Equipment and Tools at VHS Many tools here can be dangerous. All dangerous tools are members only. Non-members are welcome to use our soldering irons, hand tools, and test gear. When you add tools, please put follow this template! ---------- 3D Printing

drill_press - Add missing template fields

🇨🇦 · VHS · ccressent (ccressent@undisclosed.example.com)

Wen 4212 10" Drill Press Information: Make & Model Wen 4212 Serial Number 11938302079 04/20 User Manual Status Working as of February 2026 Training Recommended

Ventilator-regeling Project

🇳🇱 · MakerSpaceLeiden · LucasV

← Oudere versie Versie van 27 jul 2026 20:57 Regel 2: Regel 2: [[Bestand:ARE_3N_fan_controll.png|miniatuur|Are 3.0N ventilator regelkastje]] [[Bestand:ARE_3N_fan_controll.png|miniatuur|Are 3.0N ventilator regelkastje]] {{Project {{Project |Name=ventilator-regeling |Name=ventilator-regeling // fan control |Status=In Progress <!-- Start|In progress|Finished --> |Status=In Progress <!-- Start|In progress|Finished --> |Contact=Elias of Lucas of Dw |Contact=Elias of Lucas of Dw

De boa no Garoa

🇧🇷 · Garoa Hacker Clube · Gabriel Almeida

15-07-2026 ← Edição anterior Edição das 15h59min de 27 de julho de 2026 (Uma revisão intermediária pelo mesmo usuário não está sendo mostrada) Linha 2: Linha 2: ==15-07-2026== ==15-07-2026== Discussão de Plano: * Jogar jogos de tabuleiro * Jogos de tabuleiro * Discutir sobre RPGs * Discutir sobre RPGs ** D&D ** Pathfinders **Paranóia * Formar uma mesa de RPG no garoa * Formar uma mesa de RPG no garoa ** Segundas-feiras 17h30 até 20h quinzenal ou semanal (online) ** eventos exporádicos presencialmente ==12-06-2026== ==12-06-2026==

Apresentações relâmpago

🇧🇷 · Garoa Hacker Clube · Villares

← Edição anterior Edição das 01h58min de 27 de julho de 2026 (Uma revisão intermediária pelo mesmo usuário não está sendo mostrada) Linha 1: Linha 1: = == Apresentações relâmpago = == == Apresentações relâmpago no Garoa == Também conhecidas como "lightning talks" são palestras ou apresentações de apenas alguns minutos (em geral 5 ou 7 minutos) e muitas vezes com o tema livre. As pessoas se inscrevem para apresentar um assunto do seu interesse, divulgar um projeto ou uma causa. O tempo curto exige concentrar a informação, e a plateia se beneficia de uma diversa quantidade de assuntos interessantes em um curto período de tempo. Também conhecidas como "lightning talks" são palestras ou apresentações de apenas alguns minutos (em geral 5 ou 7 minutos) e muitas vezes com o tema livre. As pessoas se inscrevem para apresentar um assunto do seu interesse, divulgar um projeto ou uma causa. O tempo curto exige concentrar a informação, e a plateia se beneficia de uma diversa quantidade de assuntos interessantes em um curto período de tempo. Linha 6: Linha 6: Esse formato de apresentações é muito apreciado nos encontros e conferências da comunidade Python, tendo também sido utilizados no Garoa nos encontros de final de ano da [[Noite de Processing], entre outras ocasiões. Esse formato de apresentações é muito apreciado nos encontros e conferências da comunidade Python, tendo também sido utilizados no Garoa nos encontros de final de ano da [[Noite de Processing], entre outras ocasiões. == Próximos eventos == === 31 de julho de 2026 === Vamos receber as pessoas a partir das 19h e devemos começar as apresentações 19h30. == Eventos passados == Confira em [[Noite de Processing]]: Relâmpagos

Apresentações relâmpago

🇧🇷 · Garoa Hacker Clube · Villares

Criou página com '=== Apresentações relâmpago === Também conhecidas como "lightning talks" são palestras ou apresentações de apenas alguns minutos (em geral 5 ou 7 minutos) e muitas vezes com o tema livre. Esse tipo de formato é muito apreciado nos encontros e conferências da comunidade Python, tenho também sito utilizados nas Noite de Processing do Garoa, nos encontros de final de ano. É importante usar um relógio ou timer visível parar o público, quando o tempo term...' Página nova === Apresentações relâmpago === Também conhecidas como "lightning talks" são palestras ou apresentações de apenas alguns minutos (em geral 5 ou 7 minutos) e muitas vezes com o tema livre. Esse tipo de formato é muito apreciado nos encontros e conferências da comunidade Python, tenho também sito utilizados nas [[Noite de Processing]] do Garoa, nos encontros de final de ano. É importante usar um relógio ou timer visível parar o público, quando o tempo termina a plateia aplaude e é simplesmente impossível continuar, permitindo que a próxima apresentação comece.

TPMS

🇳🇱 · Revelation space · Bertrik Sikken

Software ← Oudere versie Versie van 27 jul 2026 09:17 (11 tussenliggende versies door dezelfde gebruiker niet weergegeven) Regel 1: Regel 1: == TPMS receiver == {{Project [[File:cc1101-module.png |thumb |right|alt=CC1101 module]] |Name=CC1101 TPMS receiver |Picture=whyunopicture.png |Omschrijving=Receiving TPMS signals |Status=In progress |Contact=bertrik }} == Introduction == == Design == The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames. Example frame, as received: 22 30 61 07 E0 1D B9 39 F5 Analysis: * byte 4: 0xE0 = wheel? * bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure * byte 7, 0x39 = 57 = temperature in Celcius? * byte 8: 0xF5 = checksum? See also https://github.com/merbanan/rtl_433/tree/master/src/devices and check for decoders starting with "tpms_". == Hardware == [[File:cc1101-module.png|right|alt=CC1101 module]] {| class="wikitable" |+Connections |- !CC1101 module !Wemos D1 mini !Remark |- |1 Ground |G |Common ground |- |2 VCC |3.3V |Common power |- |3 GD0 |D1 |"IRQ" pin |- |4 CSN |D8 |SPI Chip select (inv) |- |5 SCK |D5 |SPI clock |- |6 MOSI |D7 |SPI master out slave in |- |7 MISO |D6 |SPI master in slave out |- |8 GDO2 |D2 |"GPIO" pin, probably unused |} == Software == My experiments at: https://github.com/bertrik/esp-tpms See also: https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

syntax - created - external edit

🇨🇦 · VHS · Anonymous (anonymous@undisclosed.example.com)

Formatting Syntax DokuWiki supports some simple markup language, which tries to make the datafiles to be as readable as possible. This page contains all possible syntax you may use when editing the pages. Simply have a look at the source of this page by pressing