u/korgoaso

Daytime is mostly figured out. Higashiyama one day, Arashiyama another, Fushimi Inari early one morning, fourth day flexible. The bit i cant get a handle on is what people actually do between like 5pm and 9pm.

Most temples close around 4:30 or 5. The autumn lightups at places like Kiyomizu and Kodaiji dont really start until late october at the earliest, so late september is still well before that window.

Pontocho keeps coming up but half the comments say its a tourist strip now with food thats not really representative of kyoto. Gion sounds beautiful for a stroll but seems more of a late afternoon geisha-spotting thing. Proper kaiseki dinners apparently need booking weeks ahead which we should probably start doing now if we want a shot.

Im not trying to fill every evening with a second activity, im fine slowing down. But sitting in the hotel by 6:30 every night feels like a waste of being there. Mostly trying to get a feel for what normal evenings looked like for people who werent there during peak lightup season.

Quick background, I'm an instrumentation tech at a chemical plant on the gulf coast, been there about 7 years. Picked up my Tech license last September mostly because I wanted to do something with radio that wasn't just running a fleet codeplug somebody else built for me.

The radio I get issued at work is a Hytera HP782Ex, the ATEX IIC T4 version for the units that go into the process areas. Parent company is European so the site is spec'd to ATEX/IECEx instead of UL for most of the rated gear. So I know the platform pretty well from the user side. Our IT/comms group owns the CPS and the actual codeplug. I've never built one from scratch. I just press PTT, switch channels, talkgroups are already there.

Now I'm trying to figure out the ham DMR world and it's like learning a different language even though it's nominally the same mode. Work codeplugs are flat. 30 channels organized by area, 4 talkgroups, no contact list to speak of, no network routing decisions because the network is just our site. Ham DMR I'm looking at people's codeplugs with hundreds of contacts, dynamic vs static talkgroup logic on Brandmeister, hotspot stuff I don't fully get yet, and the whole concept of network-side timing.

Bought an AnyTone 878 as a starter because that's what the local club guys all run. Got it programmed enough to hit the local repeater. But I feel like I'm at maybe 10% of understanding what the radio is actually doing. Half the YouTube tutorials assume you already know what a TG is, the other half are aimed at people coming from FM analog who've never touched DMR at all. There isn't really a path for someone coming from the commercial side.

The real gap for me is conceptual. One piece is how experienced ham DMR ops maintain their codeplugs over time, whether you set it and leave it or it's constant edit-and-reflash. The Brandmeister side is what I really don't get. Network-side timing, talkgroup routing once you key up, all that. I've watched the standard tutorials and I'm still missing the model in my head of what's actually happening between my radio and the network.

Obviously I can't pull anything from the work codeplug, that's IT property and Part 90 vs Part 97 doesn't mix anyway, so I'm starting from zero on the personal side regardless.

Mostly trying to figure out whether the commercial background actually helps me here or it's basically a separate skill set that happens to share a protocol name.

Built a RAG service on Vercel functions about a month ago. Pinecone for vectors, OpenAI for embeddings, basic retriever, no rerank yet. P50 sits around 250ms which is fine. P99 is in the 1.5 to 2 second range, and the issue isn't the model.

It's the connection setup. On a cold function instance, the first request has to do TLS handshake to Pinecone, pull index metadata, run the embedding call to OpenAI, then hit the index. The whole chain is sequential and Vercel recycles instances often, so a meaningful chunk of traffic pays this cost. Some users see clean 250ms, others see almost two seconds for the same query against the same data.

Things I've tried that helped a little but not enough. Caching index metadata in a KV store is a marginal win. Heartbeat pre-warm via a scheduled cron job buys back maybe a third of cold instances, but Vercel scales horizontally under traffic so new instances still cold-start fresh. Dropping embedding dim shaved a few ms off but at the cost of recall, which I needed back almost immediately. None of these touched the actual ceiling, which is that doing retrieval, embedding, and reranking from a cold function is just expensive in cumulative round trips.

Where I'm stuck is whether to flip the architecture. The cleanest version is keeping the function thin and pushing retrieval to a managed service that returns final ranked results in one call. Other version is moving the whole RAG out of serverless entirely and eating the regional latency hit for stability. There's probably a third pattern I haven't figured out yet.