u/Fancy-Delivery5081

Hello,
I’m from Europe and I’m looking for an MPV or van but I want something a bit unusual. At first I considered buying a VW T5 but honestly it’s just too common and a little boring.

So far I’ve looked at vehicles like the Nissan Elgrand, Toyota Vellfire and even the VW Routan. I’m sure there are plenty of other interesting options out there but it’s surprisingly difficult to find good information, especially about models that were never officially sold in Europe.

I generally prefer JDM vehicles. For example, models like the Toyota Isis or Honda Odyssey were never officially available here, which makes them much more interesting to me.

I’m looking for recommendations for quirky, interesting or overlooked MPVs and vans, whether they’re JDM or from another market. Imports are absolutely an option, so I’m open to anything that’s a little different.

What would you recommend?

Hello together,

I do cartridge repairs for a local game shop, mostly Gen I/II stuff, battery swaps, the usual. Went through probably 200+ Pokemon carts over the years and never saw this until last week.

I have a Copy of Pokemon Gold here which acts super weird. It booted up and when i wanted to start a new game it first popped a message:

> No windows available for popping.

I started reflowing all components on the board and tried it again.

Now it acted even weirder. When i clicked "new game" it started auto-clicking A in die Professor Dialog, crashed within the Name-Select Menu and Auto-rebooted with a weird color palette and distorted music.

I went through the whole thing. New MBC3, new SRAM, every passive replaced, PCB swapped out. The error follows the ROM chip across two different boards so it's definitely in the chip itself.

Here's the weird part: I've been dumping it repeatedly and the results are all over the place depending on temperature and contact quality. Sometimes 1313 wrong bytes, sometimes 2, and after a fresh reflow and ultrasonic clean I got a bitperfect dump. Checksum valid, CRC matches, zero differences against a reference. Put it in the Gameboy straight after. Same error. I even tried to heat up the PCB and ROM to different Temps to have more success and it started to act "better".

So the ROM dumps fine but won't boot. Best explanation I have is that it handles the slow read timing of the flasher fine but chokes on the Z80 running at full speed. Something in the address line path that's just a bit too slow for 4.19 MHz.

I've been writing everything up because there's basically nothing documented about this anywhere. One old Glitch City thread from 2010 and a few Reddit posts with no resolution.

Full write-up with dump analysis and all the data is here if anyone wants to dig in: https://github.com/jw0710/pokemon-gsc-reverse-engineered-no-windows-available-for-popping

Mainly posting to ask: has anyone actually seen this on a physical cart? And if so, did you ever figure out what caused it? Based on what I know so far, I’m afraid I have to write the cartridge off as dead... That would be a shame and the first one out of over 100 that is truly beyond repair.

The only thing I can think of at this point is a broken bond wire on the die itself. Would need to get it X-rayed to confirm. Currently looking for someone with the right equipment.

Hi everyone, I'm stuck on a thermal monitoring project and have run out of ideas..
I'm building a thermal monitoring system for a BGA rework station. The goal is to monitor up to 4 Type-K thermocouples simultaneously during BGA reflow/rework operations and display live temperature curves on a connected monitor. The system runs on a Raspberry Pi Zero W v1.1 on a custom PCB, boots directly into a Python/matplotlib dashboard via systemd autostart, and is powered by a single 5V/5A supply.

Hardware:

• Raspberry Pi Zero W v1.1
• Custom PCB with 4x MAX31856MUD (TSSOP-14), assembled by JLCPCB (standard assembly service, no functional testing)
• AMS1117-3.3V LDO regulator
• Raspberry Pi OS Lite (Trixie, fully updated)

Symptoms:

• SPI is enabled (/dev/spidev0.0 and /dev/spidev0.1 present)
• All registers read 0x00 – including register 0x01 (CR1) which should default to 0x03 according to the datasheet
• Write operations have no effect (write 0x55, read back 0x00)
• adafruit_max31856 library throws no exceptions but always returns 0.0°C
• fault['open_tc'] shows False even when no thermocouple is connected (which is physically impossible)

What I have measured/verified:

• AVDD (Pin 5) → AGND (Pin 1): stable ~3.3V ✅
• DVDD (Pin 8) → DGND (Pin 14): stable ~3.3V ✅
• CS pin (GPIO8) at idle: ~3.3V (HIGH = correct) ✅
• Routing verified: Pi Pin 19 (MOSI/GPIO10) → MAX31856 Pin 11 (SDI) ✅
• Routing verified: Pi Pin 21 (MISO/GPIO9) → MAX31856 Pin 12 (SDO) ✅
• IC marking: MAX31856MUD ✅
• Pin 1 orientation (square pad): matches between PCB footprint and physical IC ✅

What I have tried:

1. Tested all 4 SPI modes (0-3) – all return 0x00
2. Hardware CS vs. software CS (manual GPIO control) – no difference
3. Bit-banging with RPi.GPIO – no difference
4. Swapped MOSI/MISO jumpers at the Pi header – briefly got realistic-looking values (once 16°C, otherwise 8-9°C) but write operations still had no effect and values never changed with temperature
5. Enabled SPI1 (dtoverlay=spi1-3cs) – OSError: Invalid argument
6. External 3.3V source (Arduino) directly on AVDD/DVDD – no difference
7. start_autoconverting() + unpack_temperature() – returns values but they never change regardless of temperature applied (heat gun, fingers, etc.)

Known design issue: Pin 1 of the Pi GPIO header was accidentally connected to AMS1117 VOUT, meaning the Pi's internal 3.3V regulator and the AMS1117 were fighting each other on the 3V3 rail. I have since cut this connection. Tested with external 3.3V supply as well – no change in behavior.

Test code:

python

import spidev
import time

for mode in range(4):
    spi = spidev.SpiDev()
    spi.open(0, 0)
    spi.max_speed_hz = 500000
    spi.mode = mode
    result = spi.xfer2([0x01, 0x00])
    print(f"Mode {mode}: Reg 0x01 = 0x{result[1]:02X}")
    spi.close()
    time.sleep(0.1)

Output: 0x00 on all modes.

My question: What could cause the IC to seemingly respond (no exceptions, open_tc False) while all registers read 0x00 and write operations have zero effect? Could this be a footprint issue even though Pin 1 orientation appears correct? Is it possible the IC is damaged from the 3V3 rail conflict? Any ideas appreciated – this has been a very long debug session! 😅

(Text translated with AI - not native english, excuse me)